安全帳號管理器（SAM）結構 [BY refdom]

安全帳號管理器（SAM）結構 [10-01-13]  所屬類別[SAM]文章作者：refdom
來自：refdom_at_263.net
導言：Microsoft的windows作業系統使用SAM檔案對登陸賬戶進行資訊儲存。

I、 摘要
II、 關於SAM
III、註冊表中SAM資料庫的結構
IV、 SAM資料庫的結構和主要內容
V、 關於SAM資料庫分析的結論

一、摘要
分析安全帳號管理器結構是在一個多月前做的事情了，只零碎地記錄下片段，沒有發布過。不發布的主要
原因是安全帳戶管理器（SAM）是WIN系統帳戶管理的核心，並且非常系統化，我也有很多地方僅僅是進行的推
斷和猜測，同時，SAM hack可能造成啟動時lsass.exe載入帳戶管理器出錯，即便是安全模式也不能修複（啟動
時候必然載入SAM）使得整個系統啟動崩潰（我通常需要依靠第二系統刪除SAM檔案來啟動）。至於現在發布出
來，主要是因為Adam和叮叮的《複製管理員帳號》種所描述的製作rootkit辦法隱蔽性和危害性，對SAM的結構
的熟悉，可以協助安全維護人員做好安全檢測（當然也可能讓不良企圖者利用）。
這裡只介紹關於SAM的內容，同Security相關的暫時不公開。

二、關於SAM
不要誤解了SAM，這不是一個檔案sam這麼簡單。SAM（Security Accounts Manager安全帳戶管理器）負責
SAM資料庫的控制和維護。SAM資料庫位於註冊表HKLM/SAM/SAM下，受到ACL保護，可以使用regedt32.exe開啟注
冊表編輯器並設定適當許可權查看SAM中的內容。SAM資料庫在磁碟上就儲存在%systemroot%system32/config/目
錄下的sam檔案中，在這個目錄下還包括一個security檔案，是安全資料庫的內容，兩者有不少關係。
SAM資料庫中包含所有組、帳戶的資訊，包括密碼HASH、帳戶的SID等。這些內容在後面詳細介紹。以我分
析的系統中文Win2K Adv Server為例。

三、註冊表中SAM資料庫的結構
展開註冊表HKLM/SAM/SAM/:
HKLM---SAM
|---SAM
|---Domains
| |---Account
| | |---Aliases
| | | |---Members
| | | |---Names
| | |---Groups
| | | |---00000201
| | | |---Names
| | | |---None
| | |---Users
| | |---000001F4
| | |---000001F5
| | |---000003E8
| | |---000003E9
| | |---Names
| | |---Adaministrator
| | |---Guest
| | |---IUSR_REFDOM
| | |---IWASM_REFDOM
| |---Builtin
| |---Aliases
| | |---00000220
| | |---00000221
| | |---00000222
| | |---00000223
| | |---Members
| | | |---S-1-5-21-1214440339-706699826-1708537768
| | | |---000001F4
| | | |---000001F5
| | | |---000003E8
| | | |---000003E9
| | |--- Names
| | |---Administrators
| | |---Users
| | |---Guests
| | |---Power Users
| |---Groups
| | |---Names
| |
| |---Users
| |---Names
| |---RXACT
這是我機器上註冊表中的SAM樹。
對照SAM檔案中的內容，可以看出，註冊表中的SAM樹實際上就是SAM檔案中一樣。不過，SAM檔案中是先列
RXACT然後在是Domains內容（以此類推），檔案中的表達順序和註冊表中的樹形順序是相反的。如果習慣於看
檔案內容，從檔案的0000h到0006Ch，表示的是SAM資料庫所在的位置：/systemroot/system32/config/sam，然
後是一端空白，直到01000h（hbin），從這裡開始就是整個資料庫的內容。SAM資料庫的檔案內容不作主要介紹，
不過會穿插著介紹，有興趣可以自己去研究。

四、SAM資料庫的結構和主要內容：
在整個資料庫中，帳號主要內容存在於下面這些位置：
在/Domains/下就是域（或本機）中的SAM內容，其下有兩個分支“Account”和“Builtin”。
/Domains/Account是使用者帳號內容。
/Domains/Account/Users下就是各個帳號的資訊。其下的子鍵就是各個帳號的SID相對標誌符。比如000001F4，
每個帳號下面有兩個子項，F和V。其中/Names/下是使用者帳號名，每個帳號名只有一個預設的子項，項中類型不
是一般的註冊表資料類型，而是指向標誌這個帳號的SID最後一項（相對標識符），比如其下的Administrator，
類型為0x1F4，於是從前面的000001F4就對應著帳戶名稱administrator的內容。由此可見MS帳號搜尋的邏輯。
推斷一：從註冊表中結構來看帳號，如果查詢一個帳戶名稱refdom的相關資訊，那麼，微軟從帳號名refdom中
找到其類型0x3EB,然後尋找相對標誌符（或者SID）為000003EB的帳號內容。所有的API函數（比如NetUserEnum()）
都是這樣來執行的。因此，如果改變refdom帳號中的類型0x3EB為0x1F4，那麼這個帳號將被指向類000001F4的帳
戶。而這個帳號000001F4就是administrator帳戶，這樣，系統在登入過程中就把refdom帳號完全轉為了administrator
帳號，帳號refdom所使用的所有內容、資訊都是adminisrtator內容，包括密碼、許可權、案頭、記錄、訪問時間等
等。這個推斷應該成立，但是，將意味著兩個使用者名稱對應一個使用者資訊，系統啟動上應該會發生錯誤！
推斷一是在以前分析結構的時候即得出了，揭示了登入過程中及之後帳戶名稱和SID關聯的關係。
/Domains/Account/Users/000001F4，這就是administrator的帳戶資訊（其他類似）。其中有兩個子項V和F。
項目V中儲存的是帳戶的基本資料，使用者名稱、使用者全名(full name)、所屬組、描述、密碼hash、注釋、是否可以更
改密碼、帳戶啟用、密碼設定時間等。項目F中儲存的是一些登入記錄，比如上次登入時間、錯誤登入次數等，還
有一個重要的地方就是這個帳號的SID相對標誌符。
以前分析結構的時候沒有留意到這個地方，這就是Adam提出的思路。這個地方就是這個SID相對標誌符在註冊
表中一個帳號出現了兩遍，一個是在子鍵000001F4，另一個地方就是子鍵中項F的內容裡面，從48到51的四個位元組：
F4 01 00 00，這實際上是一個long類型變數，也就是00 00 01 F4。當一個標誌出現在兩個地方的時候就將發生
同步問題。明顯，微軟犯了這個毛病。兩個變數本應該統一標誌一個使用者帳號，但是微軟把兩個變數分別發揮各自
的作用，卻沒有同步統一起來。
子鍵中000001F4用來同使用者名稱administrator對應，方便通過使用者查詢帳戶資訊，比如LookupAccountSid（）等
帳號相關API函數都是通過這個位置來定位使用者資訊的，這個關聯應該是用在了帳戶登入以後。而項目V值中的
F4 01 00 00是同帳戶登入最直接相關聯的。
推斷二：WIN登入的時候，將從SAM中獲得相對標誌符，而這個相對標誌符的位置是V值中的 F4 01 00 00。但是，
帳戶資訊查詢卻使用的SAM中子鍵內容。
推斷二的原因假設（假設一）：在帳戶登入的時候，登入過程獲得SAM資料庫中使用者名稱使用的客戶紀錄資訊中的
相對標誌符值（相當於V值中的 F4 01 00 00），帳戶登入之後，所有跟帳戶相關的之後，這個值不再被API函數使
用，而相對標誌符由一個資料記錄項的欄位名代替（相當於子鍵000001F4）。微軟犯了一個同步邏輯問題！
推斷二是根據Adam提出而進行的，以前沒有這樣推斷過。:( 推斷二如果成立，揭示了在登入過程中帳戶SID進行
的過程。這就是為什麼V中的值都是跟帳戶登入記錄（登入時間，密碼錯誤次數等）相關的原因。同時，因為F中儲存
了一個使用者名稱內容，而API函數查詢的是這個使用者名稱，所以Adam的複製辦法還是容易露臉，經叮叮補充過後，這個使用者
名也被恢複原使用者名稱了，從使用者名稱上檢測就相對難了。
上面對項目V的介紹可以知道，其中儲存的是帳戶的基本資料，使用者名稱、使用者全名(full name)、所屬組、描述、
密碼hash、注釋、是否可以更改密碼、帳戶啟用、密碼設定時間等。現在來關心的是密碼HASH。
假設二：在帳戶的項V中，包含了使用者HASH，分別包括是LM2和NT的密碼加密散列，Crack時，可分開進行。畢竟
LM2簡單。
/Domains/Builtin下的內容是同帳戶組相關的。其結構同/Account下的類似，並且也存在相應的問題，就不再
羅嗦了。
SAM資料庫儲存的檔案sam中，可沒有註冊表中的這麼簡明的內容，而主要是通過位移量、長度來定位內容。並
且單個帳號的資訊都是集中在一塊的，而不是象註冊表形式這樣分隔開（名字的一個鍵而內容在另外一個鍵）。
sam檔案中，可根據這些下面這些分隔字元來定位元據含義：
nk (6E 6B) 鍵或者子鍵名
vk (76 6B) 相應的值
if (6C 66) 子鍵列表
sk (73 6B) 許可權

五、關於SAM資料庫分析的結論：
SAM HACK是非常有危險性的。不正確的修改會將系統的安全資料管理器破壞，造成系統啟動問題，雖然可以通過
刪除SAM檔案來讓啟動恢複。如果能夠熟悉SAM的結構，你將發現，可以對使用者名稱與使用者名稱之間、使用者組與使用者組之間
進行調換，以及帳戶和帳戶組偽造，完全打破微軟的帳戶格局。並且非常隱蔽，讓帳戶相關的API函數摸不著頭腦。
雖然微軟處理帳號資訊中犯了不少邏輯問題，但是安全帳號資料庫並非不安全，所有操作都必須能完全擁有管理
員許可權。
當隱蔽後門的辦法被提出來之後，一定會讓不少“駭客”利用，管理員也應該多多熟悉相關技術，作好安全檢測，
我的目的就達到了。//www.blackbap.com