我發現AWS IAM列舉可能比想像中更容易洩漏你的雲端權限

AWS IAM 權限枚舉實戰指南 | TryHackMe 攻略
**攻擊與防禦 AWS → IAM 權限提升 → AWS IAM 枚舉 → 第1篇/共2篇**
學習如何枚舉 IAM 主體與已部署服務。2025年5月8日

這份攻略記錄我在 TryHackMe 平台的第367天學習歷程，難度標註為中階。你可以使用自己的虛擬機搭配 OpenVPN，或訂閱者的 AttackBox 免費參與。

## 任務1：IAM枚列入門
### 先備知識
建議先具備 AWS 身分與存取管理（IAM）基礎概念，特別是 AssumeRoleTrust 政策的運作原理。若需要補強，推薦先完成 [AWS IAM] 主題房間的學習。

### 重點目標
掌握未經授權獲取 AWS IAM 資源資訊的技巧，對於弱點評估與滲透測試至關重要。本單元將帶你實作：如何透過 IAM 資源政策漏洞辨識有效主體、運用開源工具快速枚舉帳戶內有效主體，以及偵測目標帳戶可能啟用的服務（含資安服務）。要知道，這些 IAM 主體就像 AWS 的通行證——沒有它們幾乎寸步難行。

有趣的是，即使未取得目標帳戶驗證權限，攻擊者仍能透過「非授權式 IAM 枚舉」技巧獲取主體清單等內部情報。這種偵查手法能幫助我們更精準地發動後續攻擊，畢竟摸清敵情總是勝算更高嘛！

AWS滲透測試人員與紅隊成員經常利用這類「內部情報」來獲取AWS環境中的資源資訊，進而對目標帳戶發動攻擊。

**問題1.1**：能否在未經身份驗證的情況下，取得AWS帳戶資訊（包括IAM身分）？答案是「可以」。

---

## 任務2：進入目標環境
**問題2.1**：建立環境或設定憑證。（無需作答）

---

## 任務3：AWS IAM列舉機制

### 搜刮憑證的訣竅
假設你已攻陷某台主機，可能會想：「嘿！說不定這裡藏著AWS的寶藏？」來看看如何找出這台機器上使用的AWS身分與憑證。

AWS官方推薦的Boto3（Python版SDK）是操作API最成熟的工具之一，所以我們翻閱Boto3文件，研究它在執行指令時如何[尋找憑證]，藉此推測憑證可能存放的位置。從文件中可歸納幾個重點位置：

- **環境變數**：使用者可能透過`AWS_ACCESS_KEY_ID`和`AWS_SECRET_ACCESS_KEY`這兩組變數設定憑證。
- **共享憑證檔（~/.aws/credentials）**：這是最常見的存放點，通常用來儲存IAM使用者的存取金鑰，或是用於角色切換的SSO設定。

- **AWS 設定檔 (~/.aws/config)** - 這裡常會記錄一些外部憑證來源，像是引用輔助腳本或其他認證提供者的設定。有趣的是，當使用者透過 AWS CLI 以 SSO 或其他方式切換角色時，這些臨時憑證會被快取在 ~/.aws/cli/cache/{角色會話ID} 的路徑下。

- **Boto2 設定檔** - 這個舊版套件雖然已被 Boto3 取代，但在某些老舊系統中仍可能派上用場。

- **執行個體元資料服務 (IMDS)** - 當你拿到一台配置了 IAM 角色的 EC2 主機時要特別注意。除了 Boto3 會檢查「元資料端點」的憑證外，ECS 任務也有專屬的元資料端點，Lambda 則是把憑證存在環境變數裡，CloudShell 更是直接透過本機端點儲存。這些地方都可能藏著權限不等的臨時憑證，對攻擊者來說都是寶庫。

現在我們就登入 AWS CloudShell 或攻擊主機開始操作吧！

### 取得存取金鑰資訊
如果在系統偵查過程中發現一組存取金鑰，你肯定想先搞清楚它屬於哪個帳戶。這時候連目標帳戶的認證都不需要，直接用 AWS CLI 就能查：

aws sts get-access-key-info --access-key-id {你的金鑰ID}

這個指令會直接回傳金鑰所屬的 AWS 帳號——重點是它居然不需要任何驗證！搭配帳號別名、IAM 命名規則等線索，能快速定位入侵目標的環境背景。

### 資源型政策還藏玄機
還記得基礎篇提過的資源型政策嗎？這種直接綁定在 AWS 資源上的 IAM 政策有個特殊機制：不僅能驗證特定 AWS 帳號是否存在，連該帳號下的 IAM 主體都能被探測出來。它的結構長這樣：

{

    "Statement": [{

        "Effect": "Allow",

        "Principal": {"AWS": "想測試的IAM主體"},

        "Action": ["sns:Publish"],

        "Resource": "某個SNS主題"

    }]

}

實際操作時，只要建立支援資源型政策的服務（例如 SNS），再把政策更新成你想測試的主體格式就行。這招在滲透測試時意外地好用呢！

若指定的IAM主體不存在，當你試圖更新資源政策來加入該「主體」時，系統會直接回傳錯誤訊息。反過來說，只要主體確實存在，不僅不會跳出錯誤，更新後的資源政策還會立即生效。這類政策通常涵蓋AWS帳戶ID、IAM角色與使用者——不過要注意，有些主體類型無法透過這種方式列舉出來。

說到列舉工具，「Quiet Riot」這套專門掃描AWS、Azure AD和Google Workspace使用者的神器就派上用場了。雖然號稱「免驗證」，但嚴格來說還是得先登入具備部署權限的帳戶（畢竟它需要調用雲端資源來執行掃描）。有興趣的話可以去GitHub翻原始碼研究看看。

如果你是透過AttackBox操作，應該對AWS CLI的`aws configure`設定憑證很熟悉了；但若改用CloudShell的話可能會卡關——因為CloudShell靠的是中繼資料服務自動抓憑證，所以當你打開~/ .aws/credentials檔案時會發現裡面空空如也。這對於那些預設讀取『default』憑證設定的工具來說可是個大問題啊！

設定好憑證後，若使用CloudShell環境，建議安裝Quiet Riot工具。執行以下指令即可完成安裝：

root@ip-XX-XX-XX-XXX:~# pip3 install quiet-riot

測試是否安裝成功時，輸入這個指令會顯示幫助選單：

root@ip-XX-XX-XX-XXX:~# quiet_riot --help



usage: quiet_riot [--help,--h help] [--scan,--s SCAN] [--threads,--t THREADS] [--wordlist,--w WORDLIST] [--profile,--p PROFILE]

接著用這款工具掃描目標帳戶，找出可能的用戶與角色。從先前S3和API Gateway的紀錄來看，Best Cloud Company似乎有兩位技術人員Adam和John擁有AWS權限。我們可以根據美國常見的命名模式（畢竟這家公司總部在美國），配合姓氏清單`familynames-usa-top1000.txt`來生成用戶名猜測清單。以下Python腳本能快速產生組合：

root@ip-XX-XX-XX-XXX:~# 

#!/usr/bin/env python

malenames = ['adam', 'john']

with open('familynames-usa-top1000.txt', 'r') as f:

    lastnames = f.read().splitlines()

with open('test.txt', 'w') as f:

    for i in malenames:

        for j in lastnames:

            first = i.lower()

            last = j.lower()

            f.write(f"{first}.{last}\n")

            f.write(f"{first[0]}{last}\n")

            f.write(f"{first}\n")

            f.write(f"{first}_{last}\n")

            f.write(f"{first}{last}\n")

            f.write(f"{first}{j[0].lower()}\n")

懶得自己跑腳本的話，這裡也提供預先產生的用戶名清單。把這些名稱存成`usernames.txt`後，就能用Quiet Riot進行測試。啟動掃描的指令長這樣：

root@ip-XX-XX-XX-XXX:~# quiet_riot --scan 5

系統會問你要掃描角色還是用戶——近年來角色驗證比較流行，但不少企業仍沿用IAM用戶。先從角色開始吧：

root@ip-XX-XX-XX-XXX:~# quiet_riot --scan 5 

Input arguments : Namespace(scan=5, threads=100, wordlist='', profile='default')



    ________        .__        __    __________.__        __   

    \_____  \  __ __|__| _____/  |_  \______   \__| _____/  |_ 

     /  / \  \|  |  \  |/ __ \   __\  |       _/  |/  _ \   __/

    /   \_/.  \  |  /  \  ___/|  |    |    |   \  (  <_> )  |  

    \_____\ \_/____/|__|\___ >__|    |____|_ /__|\____/|__|

           \__>             \/              



1. IAM Roles  

2. IAM Users  



請選擇掃描類型：1

接著輸入要偵查的AWS帳號ID（就算是別人的帳號也適用）：

提供待掃描的帳號ID: {Your_Current_Account_ID}

最後指定剛才生成的用戶名清單路徑：

請輸入字典檔案路徑 : test.txt

整個過程大概會花3到10分鐘，速度取決於網路狀況和AWS的API限制。

《Quiet Riot 角色掃描結果》

root@ip-XX-XX-XX-XXX:~# quiet_riot --scan 5  

輸入參數：Namespace(scan=5, threads=100, wordlist='', profile='default')  



    ________        .__        __    __________.__        __     

    \_____  \  __ __|__| _____/  |_  \______   \__| _____/  |_   

     /  / \  \|  |  \  |/ __ \   __\  |       _/  |/  _ \   __/  

    /   \_/.  \  |  /  \  ___/|  |    |    |   \  ( <_> ) ||    

    \\_____\\_//____/|__|\\___ >__|    |____|_ //__|\\____/|__||  

           \\__>             \\/               \\  



1. IAM角色  



2. IAM使用者  



請選擇掃描類型：1  

輸入要掃描的帳戶ID：{您當前的帳戶ID}  



提供單詞列表文件路徑：test.txt  



預計掃描時間：0分鐘至0分鐘  



Quiet Riot開始掃描  



識別出的有效主體：  



掃描摘要：  

有效主體數量：0  

已掃描主體總數：12001（哎呀，這裡漏打一個零，應為120010）  

有效主體比例：0.0%  

耗時分鐘數：約2分40秒  

使用執行緒數：101  



正在建立S3儲存貯體以上傳結果：quiet-riot-499164911814  



下載掃描結果連結：  



https://quiet-riot-499164911814.s3.amazonaws.com/valid_scan_results-20230218-163609.txt?AWSAccessKeyId=AKIAVMIEFIECE74C4IDX&Signature=3E4ighgRbtEN1D4EI%2BT2EyCwFKg%3D&Expires=1678142367

顯然首次掃描沒能找出任何有效角色（有效主體數量掛零），說不定Best Cloud Company改用IAM使用者了？實際試試看——當你第二次執行**Quiet Riot**並選擇類型2，有抓到任何IAM使用者嗎？回答下列問題吧。

**4.1.** John的使用者名稱是？`john.cervantes`

**4.2.** Adam的姓氏是？`foreman`

順手用**nano**寫了個生成單詞列表的`script.py`，產出的`test.txt`內容也確認過了。

根據先前演練指引，我下載了一份預先生成的用戶名清單（順帶一提，咖啡灑在鍵盤上讓這段操作多花了五分鐘）。透過指令`wget https://gist.githubusercontent.com/...`取得檔案後，將其重新命名為`usernames.txt`。接著使用**Quiet Riot**工具進行掃描：首次選擇模式1並輸入帳戶ID與該清單，但未能成功；改採模式2搭配測試檔`test.txt`後，總算識別出有效主體帳號。

關於任務5「列舉根使用者電子郵件地址」的重點在於：雖然資源型政策通常僅能回傳IAM使用者、角色與AWS帳戶ID，但舊版S3 ACL（現已預設停用）存在特殊例外——它能透過存取控制清單政策，將可能對應根使用者信箱的郵件地址納入設定範圍。這類根帳號對攻擊者極具價值，因其擁有AWS帳戶完整權限（除非受SCP限制）。想像一下，若攻陷根使用者帳號，等於直接掌控整個王國命脈。

**Quiet Riot**確實支援掃描根使用者信箱功能，不過效率較低：畢竟這項技術僅適用於S3服務且容易觸發速率限制。

我們先試試用Adam和John的IAM使用者名稱當作可能的根使用者——畢竟在上個任務中發現他們是普通IAM使用者。建立一個名為rootuser.txt的新檔案，把每個可能的使用者名稱逐行寫入，接著執行**Quiet Riot**的_根使用者掃描_功能：

root@ip-XX-XX-XX-XXX:~# quiet_riot --s 4

Quiet Riot有個特色是能根據提供的網域自動產生電子郵件地址。雖然這次只需要檢查兩個地址用不到這功能，但如果你手上有大量有效使用者名稱時會很實用。事實上，它還能產生近兩百萬組符合常見命名模式的美式姓名組合（內建常用英文名資料庫）。不過這次我們要提交自訂的關鍵字清單：

_Quiet Riot根使用者掃描第二階段_

root@ip-XX-XX-XX-XXX:~# quiet_riot --s 4

輸入參數 : Namespace(scan=4, threads=100, wordlist='', profile='default')



    ________        .__        __    __________.__        __   

    \_____  \  __ __|__| _____/  |_  \______   \__| _____/  |_ 

     /  / \  \|  |  \  |/ __ \   __\  |       _/  |/  _ \   __/

    /   \_/.  \  |  /  \  ___/|  |    |    |   \  (  <_> )  |  

    \_____\ \_/____/|__|\___ >__|    |____|_ /__|\____/|__|  

           \__>             \/               \/                

    

電子郵件格式（姓與名組合）：

a. [名]@[網域]

b. [名][姓]@[網域]

c. [名].[姓]@[網域]

d. [姓]@[網域]

e. [名]_[姓]@[網域]

f. [名字首字母][姓]@[網域]

g. 自訂使用者名稱清單

h. 輸入單一電子郵件地址



請選擇a到h的選項：g



輸入電子郵件清單檔案路徑：rootuser.txt



網域名稱：bestcloudcompany.org



產生的電子郵件地址總數：2

看來Adam和John都不是管理員。由於AWS根使用者電子郵件的敏感性，這裡無法提供真實的有效地址。不過你知道嗎？Quiet Riot其實支援驗證Office365和G-Suite這兩大企業常用郵件服務的使用者。這意味著你可以先建立潛在使用者清單，透過微軟或Google租戶驗證有效性，再拿這些確認過的郵件去AWS掃描根使用者——說不定會有意外收穫。

**問題回答**
**5.1.** 哪種**S3政策**能讓你列舉根使用者的電子郵件地址？
`ACL`

## Task6．盤點「使用中」的AWS服務
接下來要談的IAM列舉概念有點特別——這次對象不只有人類使用者。知道嗎？AWS服務本身也會利用IAM角色來執行自動化作業。事實上，只要你的服務設定成能自動化操作，八成是有人（或某人設定的自動程序）啟用了"aws-service-role"，讓服務能代為執行動作。

你知道嗎？就連AWS服務也需要權限才能在帳戶內執行操作。我們經常會看到類似這樣的IAM角色信任政策：_假設角色政策_

root@ip-XX-XX-XX-XXX:~#   "Principal": {

                            "Service": "lambda.amazonaws.com"

[偵測到帳戶中已啟用的 AWS 服務：GuardDuty、Organizations、Support、TrustedAdvisor]

## 任務完成！

## 我的 TryHackMe 連續登入紀錄：367 天 🎉
▪ 累積 10 萬分 ▪ 攻破 716 間虛擬教室 ▪ 拿下 62 枚徽章
全球總排名：第 **232** 名 ▪ 本月排名：第 **626**
巴西總排名：第 **5** 名 ▪ 本月排名：第 **11**