企业官网建设流程全解析

前言：为什么票据伪造是域对抗的终极手段

Windows域的整体权限架构，完全依托Kerberos协议完成身份认证与权限分发。内网渗透里常见的哈希传递、SMB重放、普通LDAP提权，都属于短效攻击，一旦用户修改密码、终端重置哈希，攻击链路会直接失效。

但票据伪造完全不同，它不绑定终端本地哈希、不受用户密码变更影响，拿下核心密钥后就能实现全域无差别长效驻留，这也是它能成为域对抗终极持久化手段的核心原因。

一线运维和蓝队人员普遍存在认知误区，觉得域内沦陷后，只要修改域管密码、清空终端哈希、重启服务器，就能彻底清除攻击者权限。真实攻防场景里这种操作基本无效。攻击者只要提前导出krbtgt密钥，就彻底脱离了域账号的密码认证体系，相当于手握全域通用的“万能通行证”。哪怕企业全网所有账号统一重置密码、清理所有终端登录痕迹，攻击者依旧可以伪造高权限票据，登录域控、读取NTDS密码库、接管整个域环境。

早年红队域内驻留基本依赖金票，上手简单、工具适配性强，适合快速拿权。但近几年企业蓝队体系逐步完善，绝大多数政企、国企、大型私企的SIEM和SOC设备，都默认开启了4768与4769日志链路校验，传统金票的特征被精准命中，存活率大幅下降。钻石票作为金票的迭代攻击方式，完美补齐了所有检测短板，凭借无日志异常、无参数特征、加密合规的特点，成为目前红蓝对抗中最难溯源、最难拦截、漏报率最高的域内高阶驻留手法。

本文摒弃网上千篇一律的教科书式协议堆砌，结合多次真实域入侵应急复盘经验，从协议底层原理、攻击链路拆解、工具实操落地、红队隐匿规避、蓝队溯源检测、全域安全加固六个维度，输出全套可直接复用的攻防方案，兼顾新手入门学习和资深安全人员实战落地。

2 基础底层：Kerberos协议与票据伪造核心逻辑

想要真正吃透票据伪造攻防，不用死记硬背RFC协议文档，抓准两个核心本质就能贯通所有攻防逻辑。一是域内所有高权限票据，全部由KDC域控统一签发；二是用户的实际操作权限，完全由PAC字段定义。市面上所有Kerberos票据攻击，无非就是通过各种手段篡改PAC权限、伪造合法签名，绕过KDC和终端的原生校验机制。

2.1 域环境Kerberos三方认证架构

Kerberos采用经典的三方认证架构，全程不传输用户明文密码，依靠票据加密和密钥签名建立身份信任，有效避免明文泄露风险，这也是Windows域长期沿用该协议的核心原因。整个认证体系由客户端、KDC域控、业务服务端三方构成，域内所有终端登录、账号认证、服务访问行为，全部由KDC统一管控，不存在独立的认证通道。

KDC承载域内核心认证能力，内部两大服务分工明确，直接决定票据的生成、校验与授权逻辑：

AS服务：对接客户端初始认证请求，校验用户账号密码或哈希凭证，认证通过后，向客户端发放TGT票据。

TGS服务：接收客户端携带的合法TGT票据，完成票据合法性校验后，根据用户原有权限，签发对应业务服务的ST票据。

日常工作中我们用到的域控登录、文件共享访问、LDAP数据查询、域策略修改等所有操作，都需要通过TGT+ST的双层票据校验机制完成权限认证，缺一不可。

2.2 TGT、ST、PAC的实战作用

TGT相当于域内的通用通行凭证，由krbtgt账户的专属密钥加密签名，在设定有效期内，持有者可以无限次向KDC申请各类业务的ST票据，无需重复进行账号认证。ST属于专项服务凭证，针对性极强，仅能用于访问对应IP、对应端口的指定服务，单次访问有效，无法复用。

很多人误以为票据内的用户名决定权限，这是典型认知误区。Windows系统不会解析票据表层的用户名来判定权限等级，核心只读取内嵌在TGT中的PAC特权属性证书。PAC字段封装了用户唯一SID、所属用户组SID、系统特权标识、登录权限、域内操作权限等所有核心授权信息，是域权限体系的真正核心载体。

这也是所有票据伪造攻击的核心突破口：只要攻击者篡改PAC内部的权限数据，同时保证票据签名合法、通过系统校验，系统就会无条件赋予对应高权限，完全无视账号本身的原始权限。

2.3 krbtgt账户的核心价值

krbtgt是Windows域控内置的专属系统账户，系统默认限制人工登录，不参与任何日常业务认证，账号密码随机生成，且绝大多数企业不会主动修改，常年保持固定不变。微软设计该账户的唯一用途，就是统一加密、签名域内所有的TGT票据，是整个Kerberos认证体系的信任根。

域内所有合法TGT票据，签名密钥统一为krbtgt的NTLM哈希或AES密钥。这就意味着，谁掌握了krbtgt密钥，谁就掌控了全域票据的签发权限，等同于完全接管整个域的身份认证体系，拥有任意提权、任意登录、任意横向移动的能力。

多年应急复盘下来，我总结出一个核心判定标准：域环境真正沦陷的终极标志，从来不是攻击者拿到了域管账号密码，而是攻击者成功导出并留存了krbtgt密钥。只要该密钥泄露，域内所有账号、机器的权限体系都不再安全。

2.4 Kerberos完整认证流程图

正常业务场景下，所有TGT票据均由KDC原生生成、通过krbtgt密钥合法签名，全程可追溯、可校验。金票和钻石票的核心区别，本质就是是否依托KDC原生认证流程、是否篡改原生票据数据，这也是红蓝对抗中区分两类攻击的核心判定依据。

participant C as 客户端 participant K as KDC域控 participant S as 业务服务端 C->>K: AS_REQ 提交用户身份，申请TGT K->>C: AS_REP 返回原生TGT+会话密钥(生成4768日志) C->>K: TGS_REQ 携带TGT，申请业务ST票据 K->>C: TGS_REP 返回合法ST票据 C->>S: AP_REQ 携带ST票据访问业务 S->>C: 校验通过，授权访问(生成4769日志) ``` # 3 红队实战：金票伪造全流程与隐匿优化 金票是最基础、最经典的TGT伪造攻击，核心逻辑是完全脱离KDC服务交互，在本地人工构造完整的虚假TGT票据。工具成熟、操作门槛极低，刚入门的红队人员也能快速上手，是早期域内持久化的首选方式。但它的缺陷非常明显，特征固定且极易被现代安全设备捕获，仅适用于未部署日志审计的弱防护环境。 ## 3\.1 金票攻击前置条件 落地金票伪造不需要复杂参数，仅需四项核心信息，全部可以通过域控权限远程抓取，无需物理接触域控主机： 域名称、域唯一SID、krbtgt NTLM哈希/AES密钥、自定义授权用户名 真实渗透场景中，攻击者拿到域内高权限后，不会优先登录域控本机，避免留下登录日志。大多会直接通过DCSync协议远程同步域账号机密数据，静默抓取krbtgt密钥，全程无交互、无落地文件，隐蔽性远高于本地操作。 ## 3\.2 环境准备与工具清单 实战全程只用两款主流工具，覆盖票据抓取、生成、注入、清理全流程，无多余冗余工具，避免引入异常特征。Mimikatz主打快速抓取密钥、一键生成金票，适配快速渗透场景；Rubeus主打精细化票据管理、规避查杀、适配高阶隐匿需求，是目前红队对抗EDR、SOC的主流工具。 ## 3\.3 完整实操命令（可直接复制落地） 第一步：本地抓取krbtgt密钥（域控权限执行） ```Plain Text # Mimikatz DCSync 抓取krbtgt哈希 privilege::debug lsadump::dcsync /domain:test.local /user:krbtgt

执行命令后，控制台会直接回显krbtgt账号的NTLM哈希、AES128、AES256三组核心密钥，务必完整保存。这三组密钥是后续所有票据伪造的核心凭证，泄露后会直接造成全域权限失守。

第二步：生成自定义金票并注入内存

# 生成金票并直接注入内存 kerberos::golden /domain:test.local /sid:S-1-5-21-1234567890-1234567890-1234567890 /ntlm:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx /user:DomainAdmin /ptt

核心参数简单易懂，替换对应真实环境参数即可使用。sid填写企业真实域唯一SID，ntlm替换为刚刚抓取的krbtgt哈希，user可自定义任意账号名称。/ptt是实战核心参数，作用是将生成的恶意票据直接注入当前系统内存，无需落地本地文件，完美规避文件查杀、落地痕迹检测。

第三步：验证票据有效性

# 查看当前会话Kerberos票据 kerberos::list # 测试域控访问 dir \\dc01.test.local\C$

如果可以正常读取域控C盘共享目录，代表金票注入成功，当前普通会话已永久持有域管理员权限。哪怕后续退出登录、重启终端，只要票据未过期，依旧可以直接接管域控权限。

真实案例复盘：某中小型企业域入侵事件中，攻击者通过OA漏洞拿下内网普通终端，横向移动获取域管权限后，抓取krbtgt哈希生成金票驻留。企业运维全员重置域账号密码、清理终端痕迹后，误以为入侵已清除，结果攻击者凭借留存的金票，持续驻留内网3个月，多次渗透域控窃取核心数据，全程未被发现。

3.4 红队金票隐匿优化方案

工具默认参数生成的金票特征过于明显，在有SOC、EDR、日志审计的环境中会被秒拦截，实战中必须针对性优化规避，这也是新手红队和资深红队的核心差距。

第一，优化票据有效期。Mimikatz默认生成10年有效期的票据，远超Windows域默认10小时的票据时效，特征极其醒目。实战中手动指定有效期为8-10小时，完全匹配域策略默认配置，规避时效异常告警。

第二，更换加密算法。老旧金票默认采用RC4加密，目前绝大多数企业域环境已全面禁用RC4，仅保留AES-256加密。实战中必须通过Rubeus指定AES256密钥生成票据，和原生合法票据加密方式保持一致，规避加密算法异常检测。

第三，复用真实在线账号。不要虚构不存在的账号生成票据，极易触发异常账号提权告警。优先选择域内常态化在线的普通运维、业务账号改造，贴合正常业务行为，降低告警概率。

3.5 金票致命缺陷（蓝队核心突破口）

无论怎么优化规避，金票都存在一个无法根治的底层硬伤。金票全程本地构造、完全脱离KDC交互，域控安全日志中永远不会生成4768 TGT请求事件。但攻击者使用金票访问域内服务时，会正常生成4769 ST请求事件。

正常业务认证的日志链路一定是先有4768、后有4769，时序固定、链路完整。金票攻击永久缺失前置4768日志，链路断裂的特征无法规避，这是蓝队检测金票最简单、最高效的突破口。

4 红队高阶实战：钻石票篡改原理与极致隐匿

钻石票是专门针对金票所有缺陷迭代而来的高阶攻击手法，也是目前红蓝对抗、护网行动中的主流驻留手段。它不再凭空伪造票据，而是基于域控原生合法票据二次篡改，彻底抹除金票的日志、参数、加密三大异常特征，防护设备仅凭行为日志完全无法识别。

4.1 钻石票与金票的底层核心差异

金票的核心问题是全参数人工构造，没有任何KDC交互记录，票据序列号、时间戳、会话ID全部随机生成，日志链路天然断裂，特征一眼可辨。

钻石票完全摒弃这种模式，攻击者先以普通低权限用户身份，走完整的官方认证流程，向KDC申请一套合法原生TGT，生成完整正常日志。拿到合规票据后，再用krbtgt密钥解密票据，针对性修改PAC权限字段。

最终成型的钻石票，所有表层参数、日志记录、加密方式全部和正常业务票据一致，唯一改动的只有PAC权限数据。常规日志审计、行为分析、特征匹配的检测手段全部失效，漏报率极高。

4.2 钻石票攻击完整链路流程图

A[普通域用户正常登录] --> B[请求KDC签发TGT 生成合法4768日志]
B --> C[获取KDC原生合规TGT票据]
C --> D[攻击者利用krbtgt密钥解密票据]
D --> E[篡改PAC字段 提升为域管理员权限]
E --> F[重新签名加密 生成钻石票]
F --> G[内存注入替换原有票据]
G --> H[高权限访问域服务 生成正常4769日志]
H --> I[蓝队常规审计无任何异常]
```

A[低权限正常用户登录] --> B[向KDC申请原生TGT 生成4768日志]
B --> C[获取合法合规原始TGT票据]
C --> D[攻击者利用krbtgt密钥解密TGT]
D --> E[篡改PAC字段 提升账号权限为域管]
E --> F[重新用krbtgt密钥签名加密]
F --> G[生成钻石票并注入内存]
G --> H[利用高权限访问域服务 生成正常4769日志]
```

4.3 钻石票实战完整操作步骤

钻石票最大的优势就是全程依托合法普通用户操作，无需虚构账号、无需异常交互，完全贴合日常运维行为，隐蔽性拉满，适合长期驻留、深度对抗场景。

第一步，使用域内常态化在线的普通用户登录终端，手动刷新Kerberos票据，确保KDC生成完整、时序正常的4768认证日志，铺垫合法行为基线。

第二步：导出本机合法TGT票据，保留原生参数、时间戳、会话ID。

# Rubeus 导出当前用户原生TGT Rubeus.exe dump /nowrap

导出的票据会完整保留KDC原生生成的时间戳、会话ID、加密参数、客户端信息，无任何人工修改痕迹，为后续隐匿利用做铺垫。

第三步，使用提前抓取的krbtgt AES256密钥解密原生票据，精准修改PAC内部权限字段，将当前普通用户的SID写入域管理员、企业管理员组，开启全域系统特权。整个过程只改权限，不动其他任何参数。

# 钻石票重签注入核心命令 Rubeus.exe diamond /domain:test.local /user:user01 /aes256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx /ptt

命令执行完成后，无任何弹窗告警、无异常日志新增。当前普通用户会话瞬间拥有全域最高权限，可执行域控登录、NTDS导出、全域账号查询等高权限操作，蓝队常规检测完全无法感知。

实战见解：多数红队教程只讲钻石票生成命令，却忽略核心细节——必须使用AES密钥重签票据，RC4密钥生成的钻石票，在现代域环境中依旧存在加密特征，极易被高级EDR捕获。

4.4 钻石票极致隐匿细节优化

很多红队新手疑惑，严格按照教程生成的钻石票，为什么还是会被高端SOC设备检测？核心原因就是忽略了PAC签名和行为基线的细节优化，看似合规的票据，依旧存在细微密码学漏洞和行为异常。

第一，严格沿用原生票据生命周期。不手动修改票据起止时间、不延长有效期，完全匹配KDC原生签发的时效，杜绝时间戳异常偏移导致的设备告警。

第二，最小化篡改字段。只修改PAC内的用户组SID、特权权限标识两个核心字段，客户端地址、服务名称、随机校验码、票据版本等所有原生参数一律保留，保证票据结构和正常票据完全一致。

第三，规避行为基线告警。普通用户提权后，禁止批量、高频执行DCSync、NTDS导出、全域扫描等高危操作。实战中采用低频、分步操作，间隔数小时执行一次高权限操作，贴合普通员工运维节奏，规避行为模型检测。

4.5 钻石票唯一底层漏洞

钻石票做到了表层全合规，日志、参数、加密、行为全部无异常，但它存在一个无法修复的底层密码学漏洞，这也是蓝队唯一精准检测的突破口。篡改后的PAC内容和原有签名哈希无法匹配，形成内容与签名错位的硬漏洞。

原生合法票据的PAC明文内容、PAC签名哈希、krbtgt密钥三者完全对应，哈希校验百分百通过。钻石票只修改了PAC明文权限内容，没有同步重新计算、刷新底层签名哈希，最终导致明文内容和签名校验值不匹配。这种漏洞属于密码学层级异常，日志层面完全无法体现，只能通过专属校验工具识别。

5 蓝队实战检测：金票、钻石票精准溯源方案

多年应急响应经验告诉我，域安全防御的核心差距，从来不是设备优劣，而是运维人员是否懂底层攻击逻辑。只依赖日志审计的蓝队，只能拦截初级金票攻击，面对钻石票完全无效。只有结合日志链路检测+密码学校验+行为基线分析的三层体系，才能实现票据伪造攻击全覆盖拦截。

5.1 金票批量检测脚本（可直接落地）

针对金票日志断裂的核心特征，我编写了可直接落地的PowerShell批量检测脚本，无需人工逐行审计日志，自动遍历域控安全日志，精准筛选“有ST请求、无前置TGT请求”的异常会话，适配所有Windows域控服务器。

# 域控本地执行 筛查金票攻击痕迹 Get-WinEvent -FilterHashtable @{LogName='Security';ID=4769} -MaxEvents 10000 | ForEach-Object { $stTime = $_.TimeCreated $user = $_.Properties[6].Value $hasTGT = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4768} -StartTime ($stTime.AddSeconds(-5)) -EndTime ($stTime.AddSeconds(5)) -ErrorAction SilentlyContinue if(-not $hasTGT){ [PSCustomObject]@{ 异常时间 = $stTime 攻击账号 = $user 事件描述 = "无TGT请求 直接发起ST请求 疑似金票攻击" } } }

脚本执行后会自动输出所有疑似金票攻击的记录，包含攻击时间、恶意账号、异常描述，结果清晰无冗余，误报率极低，适合日常巡检、入侵排查、红蓝对抗自查。

5.2 基于加密算法的金票辅助检测

现阶段主流企业域环境均已禁用RC4加密协议，仅保留AES加密。任何RC4加密的TGT票据，基本可以判定为人工伪造的恶意票据，这条规则可以快速筛查大部分初级金票攻击。

# 筛查RC4加密Kerberos认证事件 Get-WinEvent -FilterHashtable @{LogName='Security';ID=4768} | Where-Object { $_.Properties[8].Value -eq "0x1" } | Select-Object TimeCreated,@{Name='User';Expression={$_.Properties[6].Value}}

5.3 钻石票专属PAC签名校验方案

钻石票无日志、无参数、无行为异常，常规检测手段全部失效，唯一有效的检测方式就是PAC签名哈希校验。通过Rubeus工具对本地所有Kerberos票据进行批量密码学校验，精准识别篡改后的恶意票据。

# 批量校验本地所有票据PAC签名 Rubeus.exe validate /all

执行命令后，重点关注输出结果中的PAC Hash Mismatch字段，出现该字段即为百分百的钻石票攻击痕迹，无任何误报，是目前行业内最权威的钻石票判定依据。

5.4 SIEM落地告警规则（可直接导入）

我整理了三条高精准、可直接导入主流SIEM、SOC、态势感知平台的告警规则，适配政企、私企、国企等各类域环境，落地即可生效：

规则1（金票告警）：安全事件ID=4769 且 同用户同时间窗口无4768事件

规则2（钻石票告警）：Kerberos票据PAC签名校验失败、哈希不匹配

规则3（辅助告警）：禁用RC4环境下出现RC4加密TGT票据

5.5 攻击溯源取证流程

日常入侵溯源无需盲目排查，固定标准化流程即可，快速定位攻击入口、入侵范围和持久化后门：

第一，提取日志中的客户端IP、终端主机名、登录账号，定位攻击入口终端。

第二，筛查该终端历史登录、进程创建、文件落地日志，确认攻击者入侵时间和初始漏洞。

第三，核查krbtgt密钥修改记录，判断攻击者是否留存持久化后门。

第四，全域筛查异常高权限用户、篡改PAC票据，排查横向扩散范围。

6 全域防御加固：从根源杜绝票据伪造攻击

复盘无数域入侵事件可以确定，所有Kerberos票据伪造攻击的根源只有两个：krbtgt密钥长期未轮换导致泄露、Kerberos协议校验策略过于宽松。普通的终端加固、账号改密、密码复杂度加固，对这类高阶攻击完全无效，必须从密钥、协议、审计三个维度做全域闭环加固。

6.1 krbtgt密钥轮换（最核心防御手段）

krbtgt密钥一旦被攻击者获取，所有历史伪造票据永久有效，不会随账号改密、机器重启而失效。定期轮换krbtgt密钥是目前清除票据后门、防御票据伪造攻击最核心、最有效的手段，没有之一。

结合政企安全规范和实战对抗经验，给出标准化轮换规则：常规企业域环境每90天完整轮换一次krbtgt密钥；一旦发生域控沦陷、密钥泄露事件，必须连续执行两轮密钥轮换。Windows域默认保留新旧双密钥，两轮轮换可彻底覆盖所有历史密钥，失效全部残留伪造票据。

密钥轮换可通过AD域模块一键执行，全程无需重启域控、不中断业务、不影响员工正常办公，适合常态化落地。

落地补充：很多企业从未轮换过krbtgt密钥，这是域安全最大的隐性漏洞，一旦被拿下密钥，整个域环境永久处于失守状态。

6.2 协议安全策略加固

通过域组策略统一禁用老旧、不安全的RC4加密算法，全域强制启用AES-256高强度加密，从加密层面拦截所有依赖老旧算法的初级票据伪造攻击，封堵基础攻击入口。

开启全域PAC强制签名校验策略，让系统主动校验每一张票据的PAC内容与签名哈希一致性，直接拒绝所有篡改后的钻石票，从协议底层拦截高阶票据攻击。

修改域Kerberos策略，统一限制票据最大有效期为8小时，杜绝超长时效恶意票据长期驻留，缩短攻击窗口期，降低入侵风险。

6.3 权限与审计加固

定期清理域内冗余管理员、废弃高权限账号，收紧普通域用户权限，严格禁止低权限用户读取LDAP机密数据、执行DCSync密钥同步操作，从权限层面缩小攻击面。

全域开启Kerberos完整安全审计日志，强制留存4768、4769、4771等核心认证事件，保证每一次票据申请、服务访问都可追溯、可溯源、可取证。

终端侧部署EDR防护策略，精准监控Mimikatz、Rubeus等渗透工具的进程行为，拦截票据抓取、票据注入、密钥导出等高危操作，从终端入口阻断攻击链路。

7 应急响应：票据伪造入侵处置标准流程

真实应急场景里，很多运维人员处置票据入侵时，会盲目修改密码、重启域控，这种操作会直接清空日志、破坏取证环境，导致无法溯源攻击入口，同时残留大量恶意后门。标准化处置流程可以完全规避这类问题：

第一步，应急隔离。第一时间隔离被入侵终端，临时封禁异常高权限账号，阻断攻击者横向移动和二次提权链路，防止攻击范围扩大。

第二步，取证留存。优先备份域控安全日志、终端进程日志、票据校验记录，固定攻击时间、攻击IP、操作行为等核心证据，禁止随意清空日志、重启设备。

第三步，密钥清零。执行两轮krbtgt密钥完整轮换，彻底失效所有新旧伪造票据，清除攻击者所有持久化后门，这是应急处置的核心步骤。

第四步，全域排查。遍历所有域用户权限、终端票据、登录记录，筛查异常提权账号、篡改PAC票据、可疑登录IP，全面清理被入侵点位，排查横向扩散范围。

第五步，加固闭环。补齐域组策略、加密策略、日志审计策略，复查域安全基线，修复漏洞与权限缺陷，避免攻击者二次入侵。

8 攻防对比与实战总结

金票攻击门槛低、特征固定，适合新手快速提权和短期驻留，在常态化日志审计的企业环境中极易被捕获，仅适用于弱防护内网渗透场景，对抗性有限。

钻石票针对性解决了金票日志断裂、参数异常、加密老旧三大缺陷，是目前红队高阶对抗、长期驻留的核心手法。它的唯一短板就是PAC签名哈希不匹配的密码学漏洞，这也是蓝队防御体系的核心突破口，所有高阶域安全防御都需要围绕该漏洞搭建。

现代域安全防御不能只依赖传统日志审计，单一检测手段完全无法应对钻石票这类高阶攻击。企业必须搭建密码学校验、密钥动态轮换、用户行为基线分析的三层立体防御体系，从攻击入口、驻留过程、权限利用全链路拦截票据伪造攻击。

纵观企业域安全风险，99%的长期驻留入侵，都源于krbtgt密钥常年不更新、Kerberos协议策略宽松、日志审计体系缺失这三类基础问题。只要落地密钥定期轮换、PAC强制校验两项核心配置，就能拦截绝大多数高阶域内攻击，大幅提升内网安全基线。

互动提问

1、你在日常红蓝对抗、内网运维或应急响应工作中，是否遇到过钻石票攻击漏报的问题？主流SOC、EDR设备分别存在哪些检测短板？

2、除了PAC签名校验、krbtgt密钥轮换这两种通用手段，你在实战中还用过哪些精准拦截、溯源钻石票的高阶方案？欢迎评论区交流实操经验。