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关联的关系。

\D

评论 (0) All

登陆 还没注册？