识别与保护特权 AD 用户的 10 种方法

攻破特权账户是大多数网络攻击的“次终目标”——一旦攻击者获得特权访问权限，便可以实现其最终目的，无论是窃取或加密信息资产，还是破坏业务运营。通常，网络犯罪分子会通过攻破本地机器上的低权限账户在网络中建立立足点。随后，他们会运用多种技术，试图夺取对组织敏感数据和系统所需的更高权限账户的控制权。在 Active Directory (AD) 环境中，真正的目标是域管理员（Domain Administrator）账户，但通常任何特权账户都可能足够。

特权管理的关键要素

拥有特权访问权限的攻击者几乎可以在您的AD domain中自由穿行，并访问您最有价值的 IT 资源。因此，为了维持安全性和合规性，必须在 AD 环境中的所有特权账户上建立强有力的身份治理与访问管理。

具体而言，确保系统和数据的安全性包含两个关键组成部分：

• 识别哪些用户对哪些 IT 资产拥有何种特权
• 检测任意账户首次获得特权访问权限的时间

必须清楚地认识到，privileged access management 并不是一次性完成的工作。随着用户被入职并更换角色，以及 IT 环境不断演进，组权限与成员身份会发生变化，安全团队需要发现任何可能是恶意或其他不当的变更。

以下是您可以采用的前 10 种方法，用于保护具有特权的用户账户免遭入侵。这些方法属于全面的安全策略，旨在防止未经授权的用户获得对 AD 的特权访问。

1. 密切管理内置的特权组，例如 Domain Admins。

诸如 Administrators、Domain Admins、Enterprise Admins 和 Schema Admins 之类的内置 AD 特权组，是最显而易见的起点。接下来要关注每台 Windows 终端上的 Local Administrators 组，它为这些系统提供特权访问。

识别这些组中每个组的成员，就像在 Active Directory Users & Computers（ADUC）中查看该组的 Membership Property（成员属性）选项卡一样简单。Get-ADGroupMember PowerShell cmdlet。如下截图所示。 当你需要快速分析多个组时，这是首选方法。

请记住，对组成员进行的定期复查只能反映该时刻组的状态。尽管如此，它仍然是一个很好的起点。

2. 检查是否存在嵌套在特权组（privileged groups）中的组。

必须检查特权组是否将任何组作为成员，因为这些嵌套组会把特权组的全部访问权限授予其成员。 例如，在下面的截图中，你可以看到 Domain Admins 组的成员之一是一个名为 LabPowerUsers 的组——这意味着 LabPowerUsers 组中的任何成员都在整个域范围内拥有管理权限。

在可能的情况下，你都应避免进行组嵌套，尤其是在特权组内部进行嵌套。因为这会为攻击者提供一种更低风险触发告警的方式，从而访问关键资源和数据——他们会把自己控制的账号添加到嵌套组中，而不是直接添加到可能受到更密切监控的上层特权组中。

如前所示，Get-ADGroupMember cmdlet 只会显示所查询组的直接成员，因此它会列出任何嵌套组，但不会列出这些嵌套组的成员。要同时显示嵌套组中的成员，可以使用下方红色标出的 LDAP 过滤器：

      param([string]$groupDn )
$s = new-object system.directoryservices.directorysearcher
$s.searchroot = new-object system.directoryservices.directoryentry
$s.filter = “(&(memberOf:1.2.840.113556.1.4.1941:=$groupDn))”
$s.propertiestoload.add(“name”)
$s.propertiestoload.add(“objectclass”)
$r = $s.FindAll()
foreach ($e in $r)
{Write-Host
$e.Properties.objectclass[$e.Properties.objectclass.Count-1]:
$e.properties.name
      

如果将这段代码保存为脚本（.GetNestedMembers.ps1），则可以按如下方式执行，并指定所需组的专有名称（Distinguished Name）：

      .GetNestedMembers.ps1 -groupDn “CN=Administrators,CN=Builtin,DC=lab,DC=local”
      

输出会显示组的名称，并列出其成员：

      group : Domain Admins
user : bosshogg
user : azuresync
user : Barry Vista
user : Randy Smith
user : AdminService
      

为了在无需承受脚本编写的麻烦和成本的情况下快速获得对提升权限的可视性，许多组织会选择投资第三方的 Privileged Access Management (PAM) 工具，例如 Netwrix PAM solution。

3. 注意组织单位（OU）的权限。

除了通过组成员身份获得权限之外，还可以在组织单位（OU）级别将控制权委派给用户。下面的截图显示：将一个组的权限委派给 Sales OU；该组的每个成员都能够完成所选任务，包括修改 Sales OU 中任意组的成员身份。

由于继承机制，跟踪 OU 权限会变得很复杂。正如 NTFS 安全性一样，上级 OU 的权限会向下传播到下级 OU 和叶子对象。由此可能导致许多用户拥有提升的权限，而这些权限往往不易发现。如下面的截图所示，它展示了 Sales OU 的所有子 OU 和叶子对象：

虽然你可以中断父 OU 的继承，但这样做可能会引发问题，例如管理者无法管理他们负责的对象。

要在访问目录对象时生成审核事件，你可以使用 AD Group Policy。转到 Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > DS Access 并配置 Audit Directory Service Changes，如下所示。

请注意，启用此审计将会生成大量日志条目，因此手动查看审计日志需要花费很长时间。此外，日志条目不会明确说明正在分配哪些权限；它们仅表明需要对特定 OU 的权限进行审查。

4. 在域控制器（DC）上查找具有等同于管理员的权限。

域控制器是运行 Windows Server 操作系统的特殊机器，并提供至关重要的身份验证和授权服务。因此，重要的是要在你的 DC 上查找具备管理员级别权限的账户。例如，服务账户可能被授予在 DC 上备份或还原文件的权限。攻击者可能会通过使用诸如 Mimikatz 之类的开源工具来发现其密码哈希，然后破解其明文密码，从而攻破这些账户。

你可以根据以下内容来识别哪些账户拥有这些权限：

• 查看“默认域控制器”策略
• 使用 PowerShell 脚本
• 使用诸如 PAM 工具 Netwrix PAM solutions

5. 找出对其他账号具有密码重置权限的用户。

重置用户账号密码的能力深受威胁行为者追捧，因为重置账号密码能够让他们获得对该账号的控制权。该权限包含在 Full Control（完全控制）权限中。您还可以按照下图所示，使用 Delegation of Control 向导将“为其他用户重置密码”的特定权限进行委派：

在下面的示例中，PC Support 组的成员被授予了重置域管理员密码的权限。因此，只要入侵了 PC support 组中任意成员的账号，攻击者就能轻松获得提升后的域范围权限。

要手动逐个排查每个 OU 和用户对象以找出谁拥有此权限既耗时又容易出错；同时尝试手动审计所有密码重置活动同样不切实际。Netwrix AD security 产品可让您轻松查看哪些账号拥有密码重置权限。下面的截图展示了一个环境：prod.net 域中的 1,000 名用户的密码可以由 15 个不同的个人进行重置：

6. 监控特权服务帐户的使用情况。

之前的提示提到，需要关注那些在 DC 上拥有与管理员等同访问权限的服务帐户。但与服务帐户相关的风险并不局限于 DC。诸如 Exchange、SQL Server、备份解决方案以及其他业务应用等工作负载通常在具有管理权限的服务帐户下运行；任何知道此类帐户凭据的人都可能将其用于恶意目的。

服务帐户的密码通常不会定期更换，甚至可能从未更换，因此通常无法明确到底是谁知道这些密码。即使服务帐户密码会定期轮换，也应审计这些帐户的登录活动，以确保它们仅用于其被分配的服务，而不是用于诸如对域控制器进行交互式登录之类的非法活动。

使用 DC 上的安全日志来判断服务帐户是否被不当使用，需要将多条信息拼凑起来。 例如，事件 4768 显示请求了 Kerberos 身份验证票据，而 4672 表示为新的登录分配了特殊权限，但这些信息需要与事件 4624（账号成功登录）关联起来。

7. 找出对应用于 DC 或运行具有域特权访问的应用程序的服务器的 GPO 具有写入权限的用户。

组策略（Group Policy）是一种强大的工具，可用于管理用户以及诸如 DC、应用服务器和 Windows 端点之类的计算机。正因如此，攻击者会试图控制它；而您必须监控谁对任何组策略对象（GPO）拥有可写访问权限，这一点至关重要。

一个很好的起点是审查所有与“域根”（Domain root）或“域控制器”OU（Domain Controllers OU）相连的 GPO 的权限。您可以通过查看默认域控制器策略（Default Domain Controllers policy）的“委派”（Delegation）选项卡来轻松完成，如下所示：

8. 识别所有能够访问任意 AD 管理解决方案的用户账户。

许多组织使用第三方解决方案来简化 AD 管理任务。有时，这些解决方案可能会为试图获得特权访问权限的威胁行为者提供两种攻击方法。

• 第一种方式是使用服务帐户或代理帐户，并授予其对 AD 全部或部分的特权访问权限，以启用该解决方案的管理功能。
• 第二种方法使用管理解决方案中被分配了权限的任意账号。在这种情况下 低权限用户可能会被授予对部分 AD 账号执行特权操作的能力（例如，重置其他用户的密码）。根据委派的级别，控制像这样的账号可能同样等效于成为域管理员（Domain Admin）。

要深入了解这些风险，你必须盘点正在使用的所有管理应用。注意，它们往往并不驻留在域控制器上。接下来，你需要识别所有具有特权访问权限的服务账号和代理账号，并监控这些账号的活动内容。大多数管理解决方案都提供某种方式来建立审计跟踪（audit trail），以监测不当行为。这些应用生成的任何告警也可以在有可用条件时转发到 SIEM 解决方案。

另外，Netwrix Auditor 可以向你的 Windows 服务器发送每日活动汇总，详细说明硬件和软件的所有变更、计划任务、应用程序、网络设置等内容。下面是一张显示所有已安装应用的截图：

9. 不要忘记虚拟化基础设施管理员。

要保护你的虚拟 AD 环境，你必须知道哪些账号对你的虚拟基础设施具有特权访问权限。请记住，任何负责管理托管 DC 或成员服务器的虚拟环境的人，都拥有相当于对物理机器进行管理的访问权限。

例如，如果你正在运行 Hyper-V，那么 Hyper-V Administrators 本地组的成员在来宾操作系统上拥有管理员级别的访问权限。同样地，在 VMware 环境中，ESXi 系统上的 root 用户也具有相同级别的访问权限。并且，尽管成员服务器可能不托管 AD，但任何具备 AD 权限的管理应用程序或服务账户都会带来相同的风险。

10. 防止管理员留下凭据痕迹（credential artifacts）。

当用户登录系统时，用户注销后往往会有部分凭据信息残留。该信息可能包括明文密码、密码哈希、NTLM 哈希以及 Kerberos 票据。攻击者可以使用诸如 Mimikatz 之类的工具，轻松利用残留在服务器和工作站内存中的这些痕迹（artifacts），以特权账户的身份完成身份验证。例如，明文密码可以直接复用；哈希也可以作为身份验证请求的一部分进行传递，并借助其他入侵工具来获取对其他系统的访问权限。

不幸的是，要识别哪些机器上存在特权凭据痕迹（privileged credential artifacts）几乎是不可能的。因此，你的重点应该放在确定特权用户正在从哪里登录（logging on）上。

如前所述，你可以在任何当前的 Windows 系统上，针对已知为特权组的组监控事件 ID 4627（Special privileges assigned to new logon）。此外，你还可以在你的 DC 上监控事件 ID 4769（A Kerberos service ticket was requested），以识别特权登录（privileged logons）。

在你了解特权账号是如何被使用之后，请确保 WDigest 设置能够防止明文密码被存储在内存中。你还应禁止特权账号在用户工作站上使用，以保障其凭据安全，并使用具有 Local Admin 权限的账号来处理终端用户问题。

牢牢掌控特权账号

特权用户账号——从仅拥有本地 Admin 权限、仅限一台机器的账号，到拥有完整 Domain Admin 权限的账号——会被攻击者定期盯上。为了防止数据泄露和停机，你需要知道哪些用户是你的特权用户，并监控可能影响特权访问的变更。然而，如果你依赖原生工具，评估和监控往往是耗时且容易出错的流程。为了实现可靠的 24/7 监控，从而保护你的特权账号免受入侵与误用，你需要自动化的第三方工具。该 Netwrix suite of solutions 为你提供所需的可视性，以检测并阻止 privilege escalation 尝试以及特权滥用。