Question

攻击者拿到活动目录权限后，会想各种方法维持已有权限，包括常见的种下木马后门和利用 AD 的特性，如 krbtgt 账号、DSRM 账号、SID History、AdminSDHolder 等。

17.3.1　krbtgt 账号与黄金票据

在介绍 Kerberos 协议时我们提到，TGT 是由 KDC 的密钥生成的，其实域中每个用户的票据都是由 krbtgt 的密码 Hash 来计算生成的，因此只要黑客拿到了 krbtgt 的密码 Hash，就可以随意伪造票据，进而使用票据登录域控制器。使用 krbtgt 用户 hash 生成的票据被称为黄金票据（Golden Ticket），此类攻击方法被称为票据传递（PTT）攻击。

黄金票据的原理是，通过伪造 TGT，没有与 KDC 进行 AS-REQ、AS-REP 通信，直接进行 TGS-REQ，向 KDC 进行请求以获得票据，其工作原理图如图 17-17 所示。

安全策略一般会要求域内的普通账号定期进行修改，或者域管理员发现入侵行为而修改了所有管理员密码，但往往会忽视 krbtgt 这个账号。这时候，攻击者利用原先导出的 krbtgt 的 HASH 生成黄金票据，导入系统缓存便可以继续控制活动目录。利用 Mimikatz 的 kerberos::golden 功能将 krbtgt 的 HASH 导入并生成票据，如图 17-18 所示。

图 17-17　黄金票据工作原理

图 17-18　生成黄金票据

利用此票据即可访问域控上的文件。

还可以利用 DCSync 功能远程导出其他用户哈希，图 17-19 为笔者在域内主机上导出 test2 账号的 HASH。

17.3.2　服务账号与白银票据

白银票据（Silver Tickets）是伪造 Kerberos 票据授予服务（TGS）的票据，也称服务票据，这中间与域控制器没有通信，即没有 AS-REQ、AS-REP、TGS-REQ、TGS-REP 过程，所以只在应用服务端才会有相应日志，白银票据工作原理如图 17-20 所示。

图 17-19　导出其他用户哈希

图 17-20　白银票据工作原理

通常服务账号也不会修改，所以只要导出服务账号的 HASH，就能利用此 HASH 生成白银票据，利用方法与黄金票据类似，不再赘述。与黄金票据不同的是，白银票据是伪造 TGS，这意味着该票据仅限于特定服务器上的服务使用。

17.3.3　利用 DSRM 账号

除了 krbtgt、服务账号之外，域控上还有一个目录服务还原模式（DSRM）账户，其密码在 DC 安装的时候就需要进行设置，所以一般不会被修改。微软对 DSRM 账号进行了限制，只允许在控制台登录。通过对 DSRM 的研究人们发现，DSRM 其实是一个可用的本地管理员账号，而且修改了如下注册表键值：

---

HKLM\System\CurrentControlSet\Control\Lsa\DSRMAdminLogonBehavior

---

将 DSRMAdminLogonBehavior 改为 2，就可以通过网络验证并登录到 DC。有了这一点，就可以利用导出的 HASH 结合 PTH 方式，持续控制 DC，即使域内用户密码都进行了修改。

建议定期修改每台域控的 DSRM 账号，并且是唯一的，同时需要对 DSRMAdmin-LogonBehavior 注册表键值进行监控。

17.3.4　利用 SID History 属性

每个用户账号都有一个关联的安全标识符（SID），这个 SID 用于跟踪安全主体在访问资源时的账户与访问权限，例如，系统默认管理员 SID 值为 500，不管怎么改名这个 SID 也不会变。

为了支持 AD 迁移，微软设计了 SID-History 属性，SID History 允许一个账户的访问被有效地克隆到另一个账户。这是非常有用的，其目的是确保用户在从一个域移动（迁移）到另一个域时能保留原有的访问权限。当 DomainA 中的用户迁移到 DomainB 时，会在 DomainB 中创建一个新的用户账户，DomainA 用户的 SID 将添加到 DomainB 用户账户的 SID 历史属性中。这将确保 DomainB 用户仍然可以访问 DomainA 中的资源 ^[1] 。

攻击者们发现，SID History 可以在同一个域中工作，即 DomainA 中的常规用户账户可以包含 DomainA SID，假如这个 DomainA SID 是一个特权账户或组，那就可以在不作为域管理员成员的情况下授予常规用户域管理员权限，相当于一个后门。Mimikatz 提供了 misc::addsid 的功能，在 2.1 版本以后需要使用 SID 模块，图 17-21 为给 test1 账号添加 SID History，注意最后的数字，我们知道 500 是默认本地管理员，512 则是 Domain Admins，这里我们以 512 为例演示。

图 17-21　给 test1 账户添加 SID History

成功后，test1 下次登录时就可以以管理员的方式登录到域控了，如图 17-22 所示。

相应的策略是监控 4738 事件，已更改的属性中会列出 SID 历史，如图 17-23 所示。

也可以定期检查 SID History 的异常账号，如图 17-24 所示。

图 17-22　利用 SID History 特性访问域控

[1] 更多关于 SID History 的信息，请访问微软官网：https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc779590(v=ws.10)。

17.3.5　利用组策略

组策略可以方便地对 AD 中计算机和用户进行管理，组策略保存为组策略对象（GPO），然后与 AD 对象（如站点、DC 或 OU）进行关联。组策略可以包括安全选项、注册表项、软件安装以及启动和关闭脚本等，域成员默认情况下每隔 90 分钟刷新一次组策略设置（域控制器为 5 分钟）。这意味着组策略会强制在目标计算机上配置相关的设置。如果黑客拿到了域管权限，也可以通过修改组策略来控制域内的计算机和用户，例如，执行登录脚本，创建计划任务，部署安装恶意软件等。即使使用了 LAPS 方案来保证每台计算机本地管理员密码不一致，拿到域控权限的黑客也可以通过在组策略里配置脚本，自动收集所有计算机本地管理员账号 LAPS 密码。

图 17-23　SID History 相关事件

图 17-24　SID History 检查

还有一个需要注意的是 SYSVOL 目录的权限，默认域内认证用户只读，如果 SYSVOL 目录或下面的子目录权限被攻击者故意修改为特定用户可写，会发生什么事情呢？我们知道组策略包括两个组件：一个是组策略容器，它存储在 AD 中；另一个是组策略模板，它存储在 SYSVOL 中，需要两者相结合这个组策略才能生效。也就是说，如果在 SYSVOL 中写入一个脚本，但没有在组策略中引用是不会造成危害的。但是如果修改一个引用的脚本，在其中引入一些其他功能，例如添加恶意用户、导出用户 HASH 等，是非常危险的。

AD 内默认有两个组策略：一个是针对全局的 Default Domain Policy；另一个是针对 DC 的 Default Domain Controllers Policy，其 UUID 都是固定的，也就是说在 SYSVOL 目录是固定的文件夹。一些脚本考虑到通用性会修改这两目录的权限，需要特别注意。

17.3.6　利用 AdminSDHolder

每个活动目录域中都有一个 AdminSDHolder 对象，它位于域的 System 容器中。设置 AdminSDHolder 的目的是防止特权用户和重要的组被无意地修改。引入这样的机制之后，那些 Protected groups 和它们的成员都得到了更进一步的安全保护 ^[1] 。通过修改 Admin-SDHolder 属性，将一个普通用户添加到“安全”选项卡里，并赋予其所有权限或者修改权限，如图 17-25 所示。

图 17-25　向 AdminSDHolder 属性中添加账户

注意：

AD 用户和计算机管理工具默认不显示 System 等对象及相关账号的“安全”选项，需要点击“查看”—“高级功能”或者右键“查看”—“高级功能”。

添加完成后，等 60 分钟自动生效，或者手工触发 SDProp 使其立即生效，如图 17-26 所示。

图 17-26　手工触发 SDProp

注意：

要以管理员权限启用 ldp.exe 进程，否则会失败。

这时候我们可以看到 Domain Admins 属性中“安全”选项卡里已经有上面添加的 test1 账号了，如图 17-27 所示。

这样我们就可以在普通主机上远程管理 AD 的权限了，例如，将 test2 加入到 Enter-prise Admins 组，如图 17-28 所示。

注意：

Windows 7 或 Windows10 默认没有 AD 管理工具，需要额外安装补丁文件，然后在系统里添加 AD DS 功能。

[1] 更多关于 AdminSDHolder 的介绍，请参考微软官方博客：https://blogs.technet.microsoft.com/apgceps/2011/10/09/adminsdholder/。

17.3.7　利用 SSP

SSPI（Security Support Provider Interface）是 Windows 系统在执行认证操作时所使用的 API，而 SSP（Security Support Provider）可以理解为一个 DLL，用来实现诸如 NTML、Kerberos、Negotiate、Credential 等身份认证。在系统启动的时候 SSP 会被加载到 lsass.exe 进程，基于 LSA 本身的可扩展特性，如果自定义一个恶意的 DLL 也会在系统启动的时候被加载到 lsass.exe。

图 17-27　Domain Admins 属性图

图 17-28　利用 AdminSDHolder 特性修改组成员

Mimikatz 里就带有一个 mimilib.dll 的文件，将这个文件拷贝到系统 system32 目录，并修改如下注册表项：

---

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Security Packages

---

将 mimilib.dll 加入到 Security Packages 值的最下面，然后重启域服务器即可生效，它会将记录到的用户密码保存到特定的文件中，如图 17-29 所示。

图 17-29　利用 SSP 获取管理员密码

试想，如果将密码文件写到 SYSVOL 共享目录某个文件里，是不是就可以长久控制域服务器？

17.3.8　利用 Skeleton Key

SSP 后门需要重启才能生效，神器 Mimikatz 提供了 Skeleton Key 功能，即在域控上执行 misc::skeleton 后，正常的用户都可以用万能密码正常登录，其利用如图 17-30 所示。

图 17-30　利用 Skeleton Key

执行后，在普通域内主机上测试，发现可以用 Mimikatz 这个万能密码登录，但权限还是原来用户的权限，如图 17-31 所示。

图 17-31　Skeleton Key 登录效果

根据图 17-31，不需要利用 HASH 进行 PTH 访问，直接用 Mimikatz 这个万能密码便可登录任何人的计算机。

17.3.9　利用 PasswordChangeNofity

SSP 与 Skeleton Key 都需要用到 Mimikatz，黑客又研究出一种新的方法，即通过 Hook PasswordChangeNotify 拦截修改的账号密码。当修改域控密码时，LSA 会先调用 PasswordFilter 判断新密码是否符合复杂度要求，如果符合则调用 PasswordChangeNotify 在系统上同步更新密码。如果将 Hook PasswordChangeNofity 的恶意代码注入 LSA 进程，当有密码修改时即可进行记录 ^[1] 。

如果将以上代码加入更多功能，例如，将密码保存在普通用户可访问的 SYSVOL 目录，或者将密码通过 HTTP 或 DNS 外发等，则会更加危险。

[1] 具体可以参考：https://github.com/clymb3r/Misc-Windows-Hacking。