Active Directory Security <- 这不是安全边界

介绍
Active Directory 101 快速回顾 AD 的工作
原理
Active Directory

Active Directory, 简而言之，是一种集成的身份和

访问解决方案，用于全球许多（或大多数）企业
网络

存储有关用户、
通过组成员身
计算机、组、 验证身份 (user,
份审核和控制
首选项等的信 computer,…)
访问
息
 Active Directory Components
Active Directory 数据存储

Domain controllers

Domain

森林

树 (DNS)

组织单元和站点

Group Policy
 Active Directory Components
Active Directory 数据存储 数据存储是磁盘上的 Active
Domain controllers Directory 数据库，包含存储在
Domain
AD 中的所有内容（包括密码哈
希）
森林

树 (DNS) 默认路径 :
组织单元和站点 C:\Windows\NTDS\ntds.dit
Group Policy
 Active Directory Components
Active Directory 数据存储 每个 DC 托管 Active Directory 数据存储和 相应
的服务 (LDAP, KDC, GC,…)
Domain controllers
换句话说： DC 是运行 AD 并提供对网络上其他
Domain
计算机的访问的服务器
森林
通常有多个（至少两个） DC 用于冗余，因为 AD
树 (DNS) 通常是企业网络中最关键的服务之一
组织单元和站点
从 Windows 2000 开始，域中的每个 DC 都可以
Group Policy 写入 AD 数据库（多主）——更改在 DC 之间同
步
 Active Directory Components
Active Directory 数据存储 树是一个连续的 DNS 命名空间
Domain controllers • eg. „corp.contoso.com“
• DNS 是 Active Directory 中的关键组件
Domain

森林
域是一种 AD 管理结构，包含
• Users, groups, computers
树 (DNS)
• Policies (e.g. Password Policy)
组织单元和站点
一个林包含一个或多个 domain
Group Policy
 Active Directory Components
Active Directory 数据存储

Domain controllers

Domain

森林

树 (DNS)

组织单元和站点

Group Policy
 Active Directory Components
Active Directory 数据存储
组织单位就像文件系统中的文件夹 ; 用
Domain controllers 于组织用户、组 ,…
Domain
站点通常描述网络的样子
森林

树 (DNS) • DCs, Computers, Users,… 可以分配到一个站点

• 通常这些对象在同一个或相邻的网络（子网）中
组织单元和站点 • 站点可用于确保计算机始终联系最近的（就网络
而言） DC 并始终使用最近的服务（关于 AD 集
Group Policy 成服务）
 Active Directory Components
Active Directory 数据存储 组策略对象 (GPO) 可被视为集中管理的设
置，适用于用户或计算机
Domain controllers

Domain
组策略从中央控制台（组策略管理控制
森林 台）进行管理，并且可以限定于特定用户、
组、组织单位等
树 (DNS)

组织单元和站点 大多数组策略设置最终会变成在目标计算
机上设置的注册表项
Group Policy
 Active Directory Components
Active Directory 数据存储 在每台 Windows 计算机上，专门的服务
(„Group Policy Client“) 检查是否有要应用
Domain controllers
的新设置
Domain
计算机设置在启动时和每 90-120 分钟后
森林 应用
树 (DNS)

组织单元和站点 用户设置在登录时应用，每 90-120 分钟

后应用一次
Group Policy
 Active Directory Components
Active Directory 数据存储
每个域控制器都托管一个可供所有域用户读取的共享
Domain controllers \\DOMAINNAME\SYSVOL\DOMAINNAME\Policies

Domain Sysvol 共享中的“ Policies” 文件夹包含所有组策略

• 每个策略都存储在一个单独的目录中，以策略
森林
的 GUID 命名
树 (DNS)
• 该文件夹可以包含不同的文件，具体取决于
GPO 设置（ .ini 、 .inf 、 .pol 、 .xml 等）
组织单元和站点 • 这些文件包含实际的配置项
Group Policy
侦察 列举所有的东西
我们想知道什
么?
我们在哪里可以找到它 ?
 Domain Admins – 域管理员

其他特权用户 (= server admin, helpdesk, developer,...)

高管 

软目标（弱密码 , 旧密码，密码未改变，从未登录的帐

我们想知道什 户 ...)

网络拓扑（基于 AD 站点，确定 IP 拓扑 )
么?
我们在哪里可以找到它 ? 组策略（弱点和保护机制到位）

软件部署（ SCCM 等）

服务和服务帐户

Delegation rights – 委派权

Protocols
• 大多数工具使用 LDAP 协议 (TCP 389) 来枚举 AD ，这在大多数
情况下是最佳选择，因为
• 结构化查询使其快速
• 如果 LDAPS (TCP 636) 可用，则对网络流量进行加密
• LDAP 日志量非常大，这使得防御者对其采取行动的成本很高
• 然而，还有一个传统的、基于 SMB 的协议，称为 SAMR
• 它很慢，没有很多工具，你只能得到有限的结果，但如果防火墙限制到
位，它会很有用
• https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-samr/4
df07fab-1bbc-452f-8e92-7853a3c7e380
 练习 1 ：侦察

Photo by Daniel Cheung

基于身份验证的攻击 NTLM, Kerberos, oh
my…
NTLM Oh boy…
NTLM 介绍
术语 NTLM 通常被用作两种不同事物的同义词

NTLM
NTLM
作为 MS-NLMP 身份验证协
用于在磁盘上存储密码的哈
议的一部分，用于通过网络
希算法
对用户进行身份验证
NTLM Intro

MS-NLMP 是一种基于质询 / 响应的身份验证方案，用于通过网络进行身份验

证

MS-NLMP 受各种“传输”协议（如 SMB 或 HTTP ）支持

MS-NLMP 包含

• LM (Lan Manager)
• NTLM (NT Lan Manager Version 1)
• NTLMv2 (NT Lan Manager Version 2)
 NTLM Summary
Protocol Hash 算法  Used for Security provided
LM 基于 DES 加密的伪哈希 - 密码存储 Extremely weak
very weak 网络身份验证
NTLMv1 MD4 密码存储 Very weak
网络身份验证
NTLMv2 MD5 网络身份验证 Weak – yeah, that's the best
we got :-(

Bottomline
NTLM 的所有口味都陈旧而弱，最好根本不要使用它们
然而，由于兼容性问题，这在现实生活中是一项非常复杂的工作
NTLM/MS-NLMP 基本认证流程
NTLM/MS-NLMP 基本认证流程
• 客户端将其 Username 发送到服务器
• 服务器生成一个随机的 16 字节数（ challenge/nonce ）并发送给客户端
• 客户端使用其密码的哈希值加密挑战并将结果发送到服务器（这是“响应”，我们
将在一分钟内跟进）
• 服务器将以下三项发送给 DC 进行验证
• Username
• 发送给客户端的 Challenge
• 从客户端收到的 Response
• DC 使用 Username 从 AD 数据库中检索相应的密码哈希并对服务器质询进行加
密
• 如果结果匹配（客户端的响应和 DC 计算的响应），则认证成功
LM/NTLM Response

请注意：为了演示目的，散列值被高度简化，并不代表真实值。
NTLMv2 Response

请注意：为了演示目的，散列值被高度简化，并不代表真实值。
NTLM Attack Vectors in a Nutshell

Pass-the-Hash
• 在不知道明文密码的情况下使用密码的哈希值对网络上的其他设备进
行身份验证。

Overpass-the-Hash
• 从 NTLM 哈希中获取 Kerberos 票证，同样在不知道明文密码的情况
下。
Relay
• 将传入的 NTLM 身份验证尝试中继到另一台主机。 可以混合使用协
议。
 Pass-the-Hash Attack
• Pass-the-Hash 攻击滥用了前面描述的事实，即只要
密码的哈希值可用，就不需要用户的密码来成功通
过网络进行身份验证

• 不再需要破解密码（！）

• 典型的攻击向量是
• 本地管理员帐户的密码哈希值，只要它们在系统中
相同（例如所有客户端）
• 从内存中获取的特权帐户（例如服务帐户或管理
员）的哈希值
 练习 2:
NTLM

Photo by Daniel Cheung

NTLM Relay Attacks
NTLM 容易受到所谓的中继攻击

在中继攻击中，攻击者将来自更高特权用户（中继帐户）的
传入身份验证请求重定向 / 中继到另一台计算机（中继目
标）
然后攻击者可以使用中继帐户的权限访问中继目标
NTLM Relay Attacks
由于协议的简单性， NTLM
身份验证得到了各种支持 支持 NTLM 的协议是（除其他外）
LDAP
„ transport protocols“ HTTP
SMB
SMTP
因此， NTLM 中继也可以跨 POP/IMAP
协议方式进行。 例如：通过
HTTP 传入身份验证，通过
SMB 传出身份验证
常见的中继向量
(1) 高特权服务帐户“ ServiceA” （通
常具有本地管理员权限）尝试访问攻 (2) 攻击者将传入的身份验证转发
击者主机 到目标主机

(4) 原始身份验证请求失败 (3) 攻击者成功通过身份验

证为“ ServiceA”
IT Admin‘s
Server Attacker Client

场景 #1 ：库存工具通过 SMB 远程查询客户

警告：攻击者主机需要是一台 Linux 机器，因为你无法在不破坏主机的情况

下禁用 Windows 中的 SMB 服务（请随意尝试）
 常用中继向量
(1) 高权限用户（例如对客户端具有本地
管理员权限的帮助台用户）尝试通过
SMB 访问受感染的主机 (4) 攻击者将传入的身份验证转发
到目标主机
(2) 攻击者阻止 SMB 流量
(5) 攻击者成功通过身份验
(3) Windows 资源管理器自动回退到 证为“ ServiceA”
IT Admin‘s
Helpdesk User HTTP (Webdav) Compromised Client
or Admin Client

场景 #2 ：帮助台用户尝试通过 SMB （使用 explorer.exe ）访问受感染的主机

在这种情况下，攻击者可以在受感染的公司机器上进行操作，因为我们通过将受害者
重定向到 HTTP 来减轻最后一种情况的 SMB 警告
Common relay vectors

(1) 攻击者引入中间人场景（ WPAD 、 (2) 攻击者将传入的身份验证转发

ARP 等） 到目标主机

(2) 受害者针对攻击者主机进 (3) 攻击者成功通过身份验

行身份验证 证为“ ServiceA”
IT Admin‘s
User Attacker Client

场景 #3 ：中间人攻击

警告：中间人场景严重依赖于目标配置和网络邻接（例如相同的子网）
Kerberos 守护冥界之门的护卫
犬
This is Jack. Jack
attends
SecureCon – a
conference for
security experts.

 初始身份验证后， AS 向 User 发出 Ticket-Granting Ticket

用户对 TGS 进行身份验证并收到 Service-Ticket （简称 TGS ）

用户使用 TGS 针对目标服务 APP01 进行身份验证

Kerberos – Step by step
Step 1 - Authentication Service Request (AS-REQ)
• 首先，用户通过 KDC 的身份验证服务 (AS) 进行身份验证以获取有效的票据授予票据
(TGT)
• 初始请求包含
• 格式为 YYYYMMDDHHMMSSZ 的 UTC 时间戳
• 使用用户的长期密钥加密（长期密钥由密码衍生而来）
• 加密类型取决于 Windows 版本
• DES-CBC-CRC (disabled since Vista/2008)
• DES-CBC-MD5 (disabled since Vista/2008)
• RC4-HMAC (XP & 2003 default)
• AES128-CTS-HMAC-SHA1-96 (introduced in Vista/2008)
• AES256-CTS-HMAC-SHA1-96 (default since Vista/2008 and newer)
Kerberos – Step by step

Step 2 - Authentication Service Response (AS-REP)

• 如果身份验证成功（正确且时间戳在容差范围内）， KDC 会向用户发出
TGT
• 将 TGT 视为一种特殊形式的服务票
• 包含特权属性证书 (PAC)
• Username
• User, Group IDs
• Group memberships
• 使用目标服务的长期密钥加密 (!)
• 由于 TGT 没有专门的目标服务，长期 key 就是“ krbtgt” 账号的 key
Kerberos – Step by step
Step 3 – Ticket-Granting Service Request (TGS-REQ)
• 客户端想要访问应用程序 / 服务并向 KDC 发送请求
• Contains TGT
• Contains target service name (service principal name)
• 如果请求有效，则会发出服务票证（请参阅步骤 4 ）。 有效的 TGT 表示 :
• Encrypted with „krbtgt“ long-term key
• Within time limits
• Important
• Kerberos 身份验证是 „ stateless“
• KDC 不“知道”用户之前是否已通过身份验证
• TGS „ 假设“ , 如果用户可以提供有效的 TGT ，则该用户已通过身份验证
• TGT 的有效性取决于“ krbtgt” 账户的长期密钥
Kerberos – Step by step

Step 4 – Ticket-Granting Service Response (TGS-REP)

• TGS （ Ticket-Granting Service ）为用户签发服务票
• 用户信息将被复制出 TGT 中的 PAC
• 服务票据使用目标服务的长期密钥加密
• Important
• KDC 不知道用户是否有权访问目标系统（身份验证与授
权）
• 授权必须由目标系统完成
Kerberos – Step by step

Step 5 – Application Server Request (AP-REQ)

• 目标服务使用长期密钥解密服务票证
• Extracts user information from PAC
• 检查权限并决定访问级别
• 可选： PAC 可以与 KDC 进行交叉检查，以确保用户信息正确
• Important
• 由于性能原因， PAC 验证通常不活跃
• 如果攻击者能够获得服务长期密钥，那么只要 PAC 未通过验证，他就
可以发行任意服务票证
Kerberos – Step by step

Optional (Step 6 / 7)
• 验证服务票证 PAC (VERIFY-PAC)
• 目标服务与 KDC 交叉验证 PAC 以验证用户信息
• 由于性能原因，通常不活跃
• Application Server Response (AP-REP)
• 用户可以在步骤 5 （相互认证）中请求对目标服务进行认证
• 服务使用会话密钥对时间戳进行加密，会话密钥应该只有用户
和服务知道，并发回给用户进行验证
Kerberos Attack Vectors in a Nutshell
Kerberoasting (TGSRoasting)
• 离线密码猜测您从网络或内存中获取的票证 .

ASREProasting
• 针对禁用（默认 = 打开）预身份验证的用户进行离线密码猜测

Pass-the-Ticket
• 类似 PTH 但是使用的是票证，仍然不知道所需的明文密码

Silver Ticket
• 针对单个服务的假票。 在一台主机上模拟任何用户

Golden Ticket
• 针对 DC 的假票。 模拟域中所有主机上的任何用户

Delegation
• 针对一位或多位房东故意伪造门票。 用一句话解释太复杂 - 稍后会详细介绍 
Kerberoasting (TGSroasting)

KDC 发出的 Service-Ticket （参见 TGS-REP ）使用目标服务的长期密钥加

密
在 RC4 的情况下，长期密钥是用户密码的 NTLM 哈希

Therefore an attacker can:

• 为任何具有弱加密 (RC4) 的主体（具有 SPN 的任何帐户）请求服务票证
• 从内存中提取票证（见 PTT ）
• 对帐户密码进行离线攻击 (hashcat -m 13200)
Kerberoasting (TGSroasting)

Kerberoasting 最适合服务帐户

• 没有人敢动他们，所以他们很少更改密码，而且密码由于年龄而经常变坏

Kerberoasting 通常不能应用于随机用户，因为用户对象默认没有
SPN

但是，如果您可以修改用户对象（想想： ACL ），那么您可以应

用目标 Kerberoasting
 练习 3:
Kerberoasting

Photo by Daniel Cheung

ASREProasting – oldy but goldy
Kerberos 预身份验证默认为所有帐户启用，
但可以在每个用户的基础上禁用

如果预认证被禁用，攻击者可以为目标用
户请求 TGT ，并对票证中的加密材料进行
离线密码猜测攻击 (hashcat -m 18200)

如果您对 Active Directory 中的对象具有

写访问权限，也可以在目标表单中使用
Pass-the-Ticket (PTT)
从内存中提取票证 (TGT/TGS) 并在不知道明文密码的情况下使用
它
如果应用于您自己的登录会话，则无需提升即可完成提取和注入
• Rubeus.exe dump
• Rubeus.exe ptt /ticket:…

PTT vs. PTH

• Kerberos 永远不会被禁用（就像 NTLM 可能是），所以它总是有效
• 然而， Kerberos TGT 的生命周期有限，约为 10 小时（取决于 GPO 设置），而
密码哈希在现实生活条件下通常至少持续一个月
Silver Ticket / Golden Ticket
Silver/Golden 描述一个场景，其中攻击者获得一个帐户的密码或密码哈希，因此可以伪造该帐户的
票证
Tickets

Silver Ticket 通常意味着针对常规帐户伪造票证 _ 通常是由于 SPN 要求而导致的服务帐户

这意味着您可以针对该帐户（或在该帐户的上下文中运行的应用程序）模拟任何帐户

Golden 意味着针对 krbtgt 帐户伪造票证，允许攻击者创建任意 TGT

Ticket
Silver Ticket

泄露帐户的密码或哈希值，并通过 Kerberos 针对该帐户

冒充任何用户

Example

• MSSQL Server 使用域帐户运行 SQL 服务

• 攻击者获取了帐户的密码哈希
• 攻击者现在可以为 sql 帐户创建一个有效的服务票证，模拟域管理员
Golden Ticket

泄露 krbtgt 帐户的密码并针对域中的任何主机冒充任何用户

Example
• 攻击者可以访问 DC 上的 AD 数据库并获取 krbtgt-hash
• 攻击者现在可以为域管理员创建一个有效的 TGT (500)
• 由于有效的 TGT ，攻击者可以使用正常程序为任何主体请求服务票证
• 因此，攻击者可以以域管理员身份访问任何域成员
Delegation
Delegation 允许主体（通常是应用程序或服务器）代表另一个主体（通常是用户）进行
操作

Active Directory 中的委派功能已作为称为 MS-SFU (S4U) 的扩展添加到 Kerberos 协议中，

如此处所述
• https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu

一言以蔽之，分为三种

• 无约束
• 约束
• 基于资源的约束 ( 由于时间限制，我们不会涵盖这个 )
Unconstrained Delegation
User01 针对计算机 SRV01 进行身份验证，该计算机已启用无约束
委派并请求该计算机的服务票证

域控制器放置一份使用副本

用户将服务票发送到计算机

计算机可以解密票证并拥有用户 TGT _ 因此，计算机现在可以在

没有任何限制的情况下模拟用户（ == 不受约束）
https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html
Unconstrained Delegation
无约束委派非常强大，因为只要您让他们对您进行身份验证，您就可以模拟任何用户（可能
也是管理员）
(think: Print Spooler Bug)

唯一的例外是账户

• 标记为敏感的委派
• “Protected Users” 组的成员

Microsoft 建议保护任何启用无约束委派的主机，就像保护 DC 一样
Unconstrained Delegation

无约束委派由 userAccountControl 属性中的标志

ADS_UF_TRUSTED_FOR_DELEGATION 控制

它可以为用户和计算机对象启用

使用 Powerview 的  "Get-DomainComputer" or "Get-DomainUser" 的“ -

Unconstrained” 参数来识别这些对象
Constrained Delegation

由于无约束委派在很多情况下可能过于无约束，微软实施了约束委
派，以允许对委派过程进行更多控制

约束委托包含两个特性

• S4U2Proxy
• S4U2Self

出站配置经典约束委派（在允许委派的主体上）
Constrained Delegation / S4U2Proxy
User01 针对启用了约束委派的计算机 SRV01 进行身份验证，
并为该计算机请求服务票证

允许 SRV01 委托给另一台名为 SRV02 的计算机

SRV01 可以向认证服务出示 User01 给自己的服务票证，并获得

User01 到 SRV02 的新服务票证

SRV01 可以拿服务票来冒充 User01 对抗 SRV02

 https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html

S4U2Proxy
Constrained Delegation / S4U2Self

由于用户可能通过 Kerberos 以外的许多不同协议进行身份验证

（例如 Web 表单、基本、 ntlm... ） S4U2Self 允许所谓的协议转换

“ 协议转换” 究竟是什么意思 ?

• 调用 S4U2Self 的主机基本上从身份验证服务向其自身请求随机用户的服务票证
• 然后主机使用这个服务票作为 S4U2Proxy 进程的输入

但是， DC 无法验证用户是否真的首先针对主机进行
了身份验证（！）
Constrained Delegation / S4U2Self

Since users might authenticate via many different protocols other than Kerberos
(e.g. web form, basic, ntlm,…) the S4U2Self allows a so called protocol transition

What does “protocol transition” mean exactly?

• A host invoking S4U2Self basically requests a service ticket for a random user to itself from the
authentication service
• The host then uses this very service ticket as an input for the S4U2Proxy process

However there is no way for the DC to verify if the user

really authenticated against the host in the first place (!)
https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html
Constrained Delegation

S4U2Proxy/S4U2Self 由两个属性控制

• 需要设置 userAccountControl 标志 TRUSTED_TO_AUTH_FOR_DELEGATION 并且属性

msds-allowedtodelegateto 应包含 SPN 形式的允许委托目标列表（例如
HTTP/host.domain.com ）

仅当设置了 TRUSTED_TO_AUTH_FOR_DELEGATION 标志时， DC 才会

在调用 S4U2Self 时返回可转发票证，并且成功调用 S4U2Proxy 需要
可转发票证
 练习 4:
Delegation

Photo by Daniel Cheung

基于 ACL 的攻击 An ACE up your sleeve
快速回顾 – 访问控制基础
Active Directory 中的访问控制
Active Directory 中的每个对象 (User, Computer, OU,…) 都有一个访问控
Key 制列表 (ACL)

facts ACLs 可用于安全或审计

ACLs 包含访问控制条目 (ACE)

ACEs 将主体与访问权限相匹配，并允许或拒绝访问

ACEs 可以通过“文件夹”继承 Active Directory 的结构（即

域、 OU ）
Access Control in Active Directory
• 您可以根据 ACE 的访问控制掩码中定义的不同类型的访问权限
授予访问权限
• https://docs.microsoft.com/en-us/windows/win32/api/iads/ne-iads-ads_right
s_enum

• 简单地说，有简单和复杂的访问权限。 一个简单的 ACE 看起来

像这样

http://www.selfadsi.de/deep-inside/ad-security-descriptors.htm#ACEInheritedTypeGUID
 Access Control in Active Directory
• 复杂的访问权限允许进一步限制对某个属性或一组属性的访问。
• 这些属性由字段“ object type/object ace type” 定义
• 复杂权限的一个例子是“ Send-As” 权限

http://www.selfadsi.de/deep-inside/ad-security-descriptors.htm#ACEInheritedTypeGUID
ACL-based vectors

基于 ACL 的向量滥用 ACL 错误配置来提升权限

根据您可以访问的对象类型，可以使用不同的技术
• User: 重置用户密码或应用定向 kerberoasting
• Computer: 使用 RBCD 获取管理员权限
• Group Policy: 部署登录脚本，安装服务 ... 无限可能 ;-)

在大型环境中分析 ACL 的最佳工具是 Bloodhound

What‘s Bloodhound?
• Bloodhound 使用图形数据库 Neo4j 来查
找可用于提升权限的 AD 对象之间的关
系
• 通过图论的力量， bloodhound 可以找到
复杂且难以使用 PowerView 或类似工具
识别的“攻击路径”
• Bloodhound 也是防御者定期测试和减少
攻击面的绝佳工具
How it works
Cypherdog

Neo4j 图数据
库

用于直接数据库访问的
Powershell 库

UI 应用程序将 ... 并允许轻松查询

LDAP 查询
JSON 文件导入到
(users, computers, groups, ACLs,...)
neo4j DB...

Bloodhound.exe (UI)
Sharphound

Windows 桌面应用程序（基于
压缩的 JSON Bloodhound User
bloodhound 的 C# 数据收集 Electron 的单页 .JS ）
器 文件
 练习 5: ACL-
based attacks

Photo by Daniel Cheung

 I am the Domain
权限维持 Controller
What‘s Persistence?

持久性描述了一种让攻击者在更长的时间范围内保持其访问权限和获
得的特权的方法

Active Directory 中最简单的持久性形式可以是特权帐户密码的知识，

尽管由于密码策略，这通常不会超过几个月

从攻击者的角度来看，一个很好的持久化方法

• 不容易被系统管理员 / 安全团队撤销或识别
• 提供对环境的长期访问（ 6 个月或更长时间）
ACL-backdoors

ACL-backdoors 是指在目录对象上使用操纵 ACL 的一类通用持久性

方法

ACL backdoors 常见示例

对高特权组的写访问权限，这允许攻击者根据需要将自己添加到组中 / 从组中删除
对组策略对象的写访问权限，允许攻击者在受影响的计算机对象上将代码作为系统运
行
• 对计算机对象的写访问权限，允许攻击者通过基于资源的约束委派获得该计算机的
管理员权限
DCSync

这允许攻击者像常规域控制器一样从 Active Directory 数据库复制内容

攻击者可以访问域中所有帐户的密码哈希值，并可以使用其他技术
（例如 Pass-the-Hash/Overpass-the-Hash ）来模拟它们

所谓的“ DCSync 权限”实际上是由两个不同的权限组成，需要在域对

象的 ACL 中授予
• Replicating Directory Changes
• Replicating Directory Changes All
Golden Ticket

Golden Tickets 是精心制作的具有任意用户名和组成员资格

的 TGT(e.g. domain admins, enterprise admins,…).

由于它们依赖于 krbtgt 帐户的密码哈希，因此金票通常具

有很长的生命周期（至少一年）。

krbtgt-hash 不会自动更改。 这必须由系统管理员发起，由

于可能存在的可用性问题，他们通常非常不愿意这样做。
 练习 6:
Persistence

Photo by Daniel Cheung

 Before we
move on…
Time for Q&A

Photo by Daniel Cheung