一个经常被遗忘(或误解)的事实是，大多数对象及其属性可以被认证的用户(最常见的是域用户)查看(或读取)。 挑战在于管理员可能认为，由于这些数据最容易通过管理工具访问，比如“ Active Directory User and Computers”(dsa.msc)或“ Active Directory Administrative Center”(dsac.msc) ，其他人无法看到用户数据(仅限于 Outlook 的 GAL 中公开的数据)。 这通常导致密码数据被放置在用户对象属性或  SYSVOL 中。

可以从活动目录收集大量数据，用于更新文档或为下一个攻击阶段侦察环境。 对于防御者来说，理解在 AD 中可以通过常规用户帐户访问的不同类型的数据是很重要的。

攻击通常以向一个或多个用户发送钓鱼电子邮件开始，使攻击者能够在目标网络内的计算机上运行他们的代码。 一旦攻击者在企业内部运行了他们的代码，第一步就是执行侦察，以发现有用的资源来升级权限、持久化，当然还有掠夺信息(通常是组织的“王冠上的宝石”)。

这篇文章展示了攻击者如何利用域用户权限侦查活动目录环境。 当许多人了解到在没有提升权限的情况下可以从AD 中收集到多少信息时，他们感到惊讶。

注意: 本文中的大多数示例使用了活动目录PowerShell 模块 cmdlet。 另一个不错的选择是 HarmJ0y 编写的 PowerView (现在是 PowerSploit 的一部分)。

我在2015年的几个安全会议(BSides，Shakacon，Black Hat，DEF CON，& DerbyCon)上谈到了其中的一些技术。 我还在“最常见的活动目录安全问题以及如何解决这些问题”一文中讨论了其中的一些问题。

获取活动目录信息

我之前已经介绍过如何通过 PowerShell 使用 .Net 来收集 AD 数据，所以我不会在本文中复制之前那篇文章中的所有 .Net 命令。

林信息：

PS C:\> [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()
Name: lab.adsecurity.org
Sites: {Default-First-Site-Name}
...

域信息：

PS C:\> [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
Forest: lab.adsecurity.org
DomainControllers: {ADSDC01.lab.adsecurity.org, ADSDC02.lab.adsecurity.org, ADSDC03.lab.adsecurity.org}
...

林信任：

$ForestRootDomain = ‘lab.adsecurity.org’
([System.DirectoryServices.ActiveDirectory.Forest]::GetForest((New-Object System.DirectoryServices.ActiveDirectory.DirectoryContext(‘Forest’, $ForestRootDomain)))).GetAllTrustRelationships()
...

域信任：

PS C:\> ([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).GetAllTrustRelationships()
SourceName:    lab.adsecurity.org
...

获取林全局目录(通常每个域控制器也是一个 GC)：

PS C:\> [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().GlobalCatalogs
Forest                     : lab.adsecurity.org
...

缓解措施：

没有合适的缓解措施。 这些信息不能也不应该被混淆或隐藏。

无需网络扫描就能发现企业服务

最简单的侦查方法是使用我称之为“SPN 扫描”的方法，它要求域控制器查询特定类型的所有服务主体名称(SPN)。 这使攻击者能够发现所有 SQL 服务器、 Exchange 服务器等。 我维护了一个 SPN 目录列表，其中包括企业中最常见的 SPN。

SPN 扫描还可以发现启用了 RDP (TERMSERV)、启用了 WinRM (WSMAN)等的 Windows 计算机。

注: 为了发现所有企业服务，将同时针对计算机和用户(服务帐户)执行扫描。

PS C:\> get-adcomputer -filter {ServicePrincipalName -like “*TERMSRV*”} -Properties OperatingSystem,OperatingSystemVersion,OperatingSystemServicePack,
PasswordLastSet,LastLogonDate,ServicePrincipalName,TrustedForDelegation,TrustedtoAuthForDelegation
DistinguishedName          : CN=ADSDC02,OU=Domain Controllers,DC=lab,DC=adsecurity,DC=org
DNSHostName                : ADSDC02.lab.adsecurity.org
...

缓解措施：

不存在相应的缓解措施。 Kerberos 需要服务主体名称才能工作。

无需网络扫描即可发现企业服务第2部分

SPN 扫描将发现所有支持 Kerberos 的企业服务。 与活动目录集成的其他企业服务通常在域“系统”容器(CN=System,DC=<domain>)中创建一个新容器。 在域的 System 容器中存储数据的一些企业应用程序包括：

• SCCM: “系统管理”

有一些应用程序，如 Exchange，在林配置分区“ Services”容器(CN=Services,CN=Configuration,DC=<domain>)中创建容器。

缓解措施：

没有合理的缓解措施。

发现服务帐户

找到服务帐户和使用帐户的服务器的最快方法是使用服务主体名称对用户帐户进行 SPN 扫描。

我的 GitHub 存储库中的 Find-PSServiceAccounts PowerShell 脚本可以在不需要 AD PowerShell 模块的情况下执行 sme 查询。

PS C:\> get-aduser -filter {ServicePrincipalName -like “*”} -Properties PasswordLastSet,LastLogonDate,ServicePrincipalName,TrustedForDelegation,Truste
dtoAuthForDelegation
DistinguishedName          : CN=svc-adsMSSQL11,OU=Test,DC=lab,DC=adsecurity,DC=org
...

缓解措施：

没有合理的缓解措施。

发现不需要网络扫描的计算机

加入活动目录的每台计算机在 AD 中都有一个关联的计算机帐户。 当连接计算机时，与这个计算机对象相关联的几个属性被更新，其中有几个非常有用。 包括:

· Created 创创建造

· Modified 修改

· Enabled 启用

· Description 描述

· LastLogonDate (Reboot) 最后登录日期 (重新启动)

· PrimaryGroupID基 本群组ID(516 = DC)

· PasswordLastSet (Active/Inactive)OperatingSystem 

· OperatingSystemVersion 操作系统版本

· OperatingSystemServicePack 操作系统服务包

· PasswordLastSet 最后设置密码

· LastLogonDate (PowerShell cmdlet attribute)

· ServicePrincipalName 服务名称

· TrustedForDelegation 信任委派

· TrustedToAuthForDelegation 委托托代理

PS C:\> get-adcomputer -filter {PrimaryGroupID -eq “515”} -Properties OperatingSystem,OperatingSystemVersion,OperatingSystemServicePack,Passwo
t,LastLogonDate,ServicePrincipalName,TrustedForDelegation,TrustedtoAuthForDelegation
DistinguishedName          : CN=ADSWRKWIN7,CN=Computers,DC=lab,DC=adsecurity,DC=org
DNSHostName                : ADSWRKWIN7.lab.adsecurity.org
...

域控制器的相同数据可以通过将 PrimaryGroupID 值更改为“516”来收集，或者通过更改为“-filter * ”来获得所有计算机。

PS C:\> get-adcomputer -filter {PrimaryGroupID -eq “516”} -Properties OperatingSystem,OperatingSystemVersion,OperatingSystemServicePack,PasswordLastSe
t,LastLogonDate,ServicePrincipalName,TrustedForDelegation,TrustedtoAuthForDelegation
DistinguishedName          : CN=ADSDC02,OU=Domain Controllers,DC=lab,DC=adsecurity,DC=org
DNSHostName                : ADSDC02.lab.adsecurity.org
Enabled                    : True
LastLogonDate              : 1/20/2016 6:46:18 AM
...

这提供了有关 Windows OS 版本以及加入活动目录的非 Windows 设备的有用信息。

查找非 windows 设备的一些示例查询：

· OperatingSystem -Like “*Samba*”

· OperatingSystem -Like “*OnTap*”

· OperatingSystem -Like “*Data Domain*”

· OperatingSystem -Like “*EMC*”

· OperatingSystem -Like “*Windows NT*”

缓解措施：

没有任何缓解措施。

识别管理员帐户

有两种有效的方法发现活动目录中权限提升的帐户。 第一种是标准组枚举方法，它标识标准活动目录管理组的所有成员: 域管理员、管理员、企业管理员等。 通常，为域“管理员”组获得递归组成员身份将提供所有 AD 管理员的列表。

第二种方法是我在2015年的 DerbyCon 会议上强调的，它涉及识别所有属性的“ AdminCount”设置为1的账户。 需要注意的是，此查询中可能返回的帐户不再具有管理员权限，因为一旦帐户从管理组中删除，该值不会自动重置。 关于 SDProp 和 AdminCount 属性的更多信息可以阅读: “Sneaky Active Directory Persistence #15: Leverage AdminSDHolder & SDProp to (Re)Gain Domain Admin Rights”。

PS C:\> get-aduser -filter {AdminCount -eq 1} -Properties Name,AdminCount,ServicePrincipalName,PasswordLastSet,LastLogonDate,MemberOf
AdminCount        : 1
DistinguishedName : CN=ADSAdministrator,CN=Users,DC=lab,DC=adsecurity,DC=org
Enabled           : True
...

注意: 这些方法不会返回具有自定义委派的管理帐户—最终不是标准AD组成员的管理帐户。

缓解措施：

没有缓解措施。期望攻击者了解更多关于哪些帐户拥有重要资源的提升权限。

查找管理员组

大多数组织都有自定义的管理员组，它们有不同的命名方案，尽管大多数都包括“管理”这个词。 为名称中带有“ admin”的所有安全组询问 AD 是获得列表的快速方法。

PS C:\> get-adgroup -filter {GroupCategory -eq ‘Security’ -AND Name -like “*admin*”}
DistinguishedName : CN=Domain Admins,CN=Users,DC=lab,DC=adsecurity,DC=org
GroupCategory : Security
GroupScope : Global
Name : Domain Admins
...

识别合作伙伴组织

外部电子邮件地址被添加到组织的全局地址列表(GAL)中，以促进合作伙伴组织之间的协作。 这些电子邮件地址是作为活动目录中的联系人对象创建的。

PS C:\> get-adobject -filter {ObjectClass -eq “Contact”} -Prop *
CanonicalName                   : lab.adsecurity.org/Contaxts/Admiral Ackbar
CN                              : Admiral Ackbar
Created                         : 1/27/2016 10:00:06 AM
createTimeStamp                 : 1/27/2016 10:00:06 AM
...

缓解措施：

唯一的缓解措施是不把联系人对象放在活动目录中，这可能是一个不确定的选项。

识别域密码策略

可以使用“ net accounts”或 AD PowerShell 模块的“Get-ADDefaultDomainPasswordPolicy”轻松枚举域密码策略。

PS C:\> Get-ADDefaultDomainPasswordPolicy
ComplexityEnabled           : True
DistinguishedName           : DC=lab,DC=adsecurity,DC=org
LockoutDuration             : 00:30:00
...

缓解措施：

没有合理的缓解措施。

识别细粒度密码策略

如果域功能级别(DFL)被设置为“ Windows Server 2008”或更高，则可以使用一个名为“细粒度密码策略(FGPP)”的新特性，以提供可应用于用户或组(非 OU)的各种密码策略。 虽然微软从 Windows Server 2008(DFL)开始就提供了细粒度密码策略，但是直到 Windows Server 2012才更新了 Active Directory Administrative Center (ADAC)来支持 FGPP 管理。 启用活动目录用户和计算机中的“ View”菜单选项的“ Advanced Features” ，然后浏览到系统，密码设置容器(CN=Password Settings Container,CN=System,DC=DOMAIN,DC=COM)通常会显示任何域 FGPP 对象。 请注意，如果没有启用“高级特性”，则系统容器不可见。

FGPP 超越了域密码策略设置，可用于要求更严格的密码策略或为一部分域用户启用限制较少的设置。

PS C:\> Get-ADFineGrainedPasswordPolicy -Filter *
AppliesTo                   : {CN=Special FGPP Users,OU=Test,DC=lab,DC=adsecurity,DC=org}
ComplexityEnabled           : True
DistinguishedName           : CN=Special Password Policy Group,CN=Password Settings Container,CN=System,DC=lab,DC=adsecurity,DC=org
LockoutDuration             : 12:00:00
LockoutObservationWindow    : 00:15:00
LockoutThreshold            : 10

缓解措施：

没有合理的缓解措施。

识别托管服务帐户和组托管服务帐户

微软增加了托管服务帐户(MSA)作为一个新的功能与 Windows Server 2008 R2 DFL 自动管理和更新 MSA 的密码。 关键的限制是 MSA 只能链接到一台运行 Windows 7或 Windows Windows Server 2008 R2(或更新版本)的计算机。

Windows Server 2012 DFL 对管理服务协议进行了必要的更新，称为组托管服务帐户(gMSA) ，它使 gMSAs 能够链接到运行 Windows 8或 Windows Server 2012(或更新的)的任意数量的计算机。 一旦将 DFL 升级到 Windows Server 2012或更高版本，默认的 AD Service Account 创建选项将创建一个新的 gMSA (例如，使用 AD PowerShell 模块的 cmdlet New-ADServiceAccount)。 在创建 gMSA 之前，需要创建 KDS Root 密钥(Add-KDSRootKey –EffectiveImmediately)。

PS C:\> Get-ADServiceAccount -Filter * -Properties *
AccountExpirationDate                      : 12/27/2017 11:14:38 AM
accountExpires                             : 131588756787719890
...

缓解措施：

没有合理的缓解措施。

识别对工作站 / 服务器具有本地管理权限的组

PowerView 已经整合了这个功能(@harmj0y 捷足先登!) 。 通过受限制的组，组策略提供了强制本地组成员身份的能力，例如 OU 中所有计算机上的 Administrators 组。 这可以通过识别使用受限组的 GPO 和它们所应用的 OU 来跟踪。 这提供了具有管理员权限的 AD 组和相关的计算机列表。

使用 PowerView (PowerSploit 的一部分) ，我们可以快速识别包含受限组的 GPO。

PS C:\> Get-NetGPOGroup
GPOName        : {E9CABE0F-3A3F-40B1-B4C1-1FA89AC1F212}
...

一旦我们有了这些信息，我们就可以使用 powerviewcmdlet 检查 GPOs 链接到什么 ou。

PS C:\> get-netOU -guid “E9CABE0F-3A3F-40B1-B4C1-1FA89AC1F212”
LDAP://OU=Servers,DC=lab,DC=adsecurity,DC=org
PS C:\> get-netOU -guid “45556105-EFE6-43D8-A92C-AACB1D3D4DE5”
LDAP://OU=Workstations,DC=lab,DC=adsecurity,DC=org

接下来，我们识别这些 OU 中的计算机。

PS C:\> get-adcomputer -filter * -SearchBase “OU=Servers,DC=lab,DC=adsecurity,DC=org”
DistinguishedName : CN=ADSAP01,OU=Servers,DC=lab,DC=adsecurity,DC=org
...

通过使用一些 PowerShell 命令，我们能够确定通过 GPO 在域中的计算机上配置了哪些具有完全管理权限的 AD 组。

缓解措施：

唯一的缓解措施是删除域用户能够读取的管理本地组的 GPO。 只有域中的计算机才需要读取和处理这些 gpo 的能力。 注意，一旦攻击者获得域中单台计算机的管理权限，他们就可以使用计算机帐户读取 GPO。

识别微软 AppLocker 设置

可以使用 Microsoft AppLocker 将应用程序的执行限制到特定的已批准的应用程序。 我为 AppLocker 推荐了几个不同的阶段：

· 阶段1: 审计模式——审计用户的所有执行和运行路径。 此日志记录模式提供关于在企业中运行哪些程序的信息，并将此数据记录到事件日志中。

· 阶段2: “黑名单模式”——将 AppLocker 配置为阻止执行用户主目录中的任何文件、配置文件路径和用户具有写访问权限的临时文件位置，比如 c:\temp。

· 阶段3: “文件夹白名单模式”-配置 AppLocker 在阶段2上构建，添加新规则，只允许在特定文件夹中执行文件，如 c:\Windows 和 c:\Program Files。

· 阶段4: “应用程序白名单”——清单列出企业环境中使用的所有应用程序，并按位置和散列(最好是数字签名)将这些应用程序列入白名单。 这可以确保只执行经过批准的组织应用程序。

问题在于 AppLocker 是通过组策略配置的，组策略通常保持在缺省状态，这使得所有域用户都能够读取配置。

缓解措施：

唯一的缓解措施是删除域用户能够阅读管理本地组的 GPO。 只有域中的计算机才需要读取和处理这些 GPO 的能力。 注意，一旦攻击者获得域中单台计算机的管理权限，他们就可以使用计算机帐户读取 GPO。

识别微软 EMET 设置

微软增强缓解体验工具包(EMET)有助于防止应用程序漏洞被利用(包括 0 day)。 它是一个免费的产品，可以有效地“封装”流行的应用程序，因此当试图利用漏洞时，尝试在“包装器”处停止，并且不会到达 OS。企业经常使用组策略来配置 EMET，这通常保持在默认状态，使所有域用户都能够读取配置。

缓解措施：

唯一的缓解措施是删除域用户能够阅读管理本地组的 GPO。 只有域中的计算机才需要读取和处理这些 GPO 的能力。 注意，一旦攻击者获得域中单台计算机的管理权限，他们就可以使用计算机帐户读取 GPO。

识别微软 LAPS 委派

微软的本地管理员密码解决方案(LAPS)是管理企业计算机本地管理员帐户密码的一个很好的选择。 LAPS 向 AD 计算机对象添加了两个新属性，一个用于存储本地的 Admin 密码，另一个用于跟踪最后一次更改密码的时间。 LAPS GPO 用于配置 LAPS 客户端，确定密码何时更改、密码长度、帐户管理等。 计算机的本地管理员密码由 LAPS 客户机在计算机上创建，该密码被设置为 LAPS 密码属性(ms-Mcs-AdmPwd)的新值，并在本地进行更改。 为了让管理员能够使用密码，需要委派对 ms-Mcs-AdmPwd 的读访问权限。 可以通过枚举属性上的安全 ACL 来识别该委托。

缓解措施：

唯一的缓解措施是让域用户无法阅读管理本地组的 GPO。 只有域中的计算机才需要读取和处理这些 GPO 的能力。 注意，一旦攻击者获得域中单台计算机的管理权限，他们就可以使用计算机帐户读取 GPO。

在 SYSVOL 共享域中发现管理员证书

管理员经常将凭证放在脚本或组策略中，最终会出现在 SYSVOL 中。

关于这个问题的更多信息包括缓解措施可以阅读: “在 SYSVOL 中查找密码并利用组策略偏好”。

总结

作为域用户，可以很容易地从活动目录收集这些有趣的数据项，这些只是其中的几个。 期望攻击者在你的企业中获得立足点，并相应地调整当前的策略。

注意: 虽然我已经有一些脚本可以执行许多这样的操作，但是我还没有准备好共享它们。 在未来的某个时候，我可能会分享这些脚本。