学习的一份记录
占坑
涉及比较多的文档内容，一开始看比较抽象并且抓不住重点，可以先搜索引擎上搜索一下文章看一看有什么内容，哪些是重点，了解一些基础知识，再去看官方文档。
- 0x00 kerberos协议
- 0x01 ntlm协议
- 0x02 看两个项目
- 0x03 管道
- 0x04 smb协议
- 0x05 windows访问控制
- 0x06 令牌窃取
- 0x07 SPN扫描&kerberoast
- 0x08 黄金票据
- 0x09 白银票据
- 0x10 MS14068
- 0x11 RPC 协议
- 0x12 DCOM 协议
- 0x13 各类 potato 提权原理
- 0x14 WinRM 协议
- 0x15 WMI 协议
- 0x16 Zerologon
- 0x17 sAMAccountName spoofing
- 0x18 CVE-2022-26923
- 0x19 bypassUAC
- 0x20 各类exec原理
- 0x21 bypassApplocker
- 0x22 看一些MicroSoft-kerberos协议的文档
- 0x23 非约束委派
- 0x24 约束委派
- 0x25 基于资源的约束委派
- 0x26
kerberos协议官方文档：https://www.ietf.org/rfc/rfc1510.txt
通过伪协议部分（A. Pseudo-code for protocol processing）理解整个认证过程
MicroSoft 对 kerberos 的扩展 S4U2：https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94
ntlm协议文档：http://davenport.sourceforge.net/ntlm.html
文档翻译项目：https://rootclay.gitbook.io/ntlm/
比较好理解，文档有大量的例子
仔细看：https://github.com/daikerSec/windows_protocol
当一个字典目录：https://github.com/Ridter/Intranet_Penetration_Tips
管道官方文档：https://learn.microsoft.com/zh-cn/windows/win32/ipc/pipes
文章：https://xz.aliyun.com/t/11971
windows访问控制文档：https://learn.microsoft.com/zh-cn/windows/win32/secauthz/access-control-model
文章：https://xz.aliyun.com/t/11981
窃取到令牌后的利用：https://github.com/hatRiot/token-priv
最常使用的是 SeImpersonatePrivilege、SeAssignPrimaryPrivilege 这两个特权
SPN官方文档：https://learn.microsoft.com/zh-cn/windows/win32/ad/service-principal-names
（1）SPN扫描是通过LDAP查询活动目录中的域用户对象或计算机对象的servicePrincipalName属性来实现的。
（2）kerberos协议认证过程中KRB_TGS_REP消息返回的KRB_TGS_REP::Ticket::EncryptedData结构是使用服务账户（域用户或计算机账户，取决于SPN设置在域用户对象还是计算机对象）哈希加密的，通过爆破该字段获取服务账户哈希。
原理：KRB_AS_REP::Ticket::EncryptedData是通过域控的krbtgt账户哈希加密的，当我们拥有域控的krbtgt账户哈希时，可以自己制作KRB_AS_REP::Ticket::EncryptedData用于后续的身份认证，黄金票据其实指的就是KRB_AS_REP::Ticket
注意一：KRB_AS_REP::Ticket::EncryptedData::EncryptionKey字段等于KRB_AS_REP::EncryptedData::EncryptionKey字段，KRB_AS_REP::EncryptedData字段是用客户端哈希进行加密的。在正常的身份认证过程当中客户端使用自己的哈希解密KRB_AS_REP::EncryptedData值以获得KRB_AS_REP::Ticket::EncryptedData::EncryptionKey值，用于解密后续身份认证过程中产生的KRB_TGS_REP::EncryptedData字段，在黄金票据制作中自己伪造一个EncryptionKey放进KRB_AS_REP::Ticket::EncryptedData::EncryptionKey即可。
注意二：mimikatz工具制作黄金票据需要域SID，这是因为KRB_AS_REP::Ticket::AuthorizationData字段是微软设计的PAC，PAC结构里面需要域组SID，而域组SID由域SID+组标识组成，比如域SID+500表示域管组。
原理：kerberos协议认证过程中KRB_TGS_REP消息返回的KRB_TGS_REP::Ticket::EncryptedData是使用服务账户（域用户或计算机账户，取决于SPN设置在域用户对象还是计算机对象）哈希加密的，当我们拥有服务账户的哈希之后，可以自己制作KRB_TGS_REP::Ticket::EncryptedData用于后续的身份认证，白银票据其实指的就是KRB_TGS_REP::Ticket。
注意一：白银票据能利用成功的前提是服务不验证PAC，当服务验证PAC时白银票据是无法利用成功的。
文章：https://daiker.gitbook.io/windows-protocol/kerberos/3#0x00-qian-yan
原理：PAC中的校验和生成如果使用HMAC系列的算法是需要服务账户哈希和krbtgt哈希作为算法的key的，但由于PAC中的服务器校验和与KDC校验和可以使用MD5算法，这就导致没有服务账户哈希和krbtgt账户哈希用户也可以自己制作PAC。
注意一：PAC是放置在KRB_AS_REP::Ticket::AuthorizationData字段中的，而KRB_AS_REP::Ticket字段是经过krbtgt哈希加密的，我们没有krbtgt哈希，构造出的PAC按理说无法填充到被krbtgt加密的Ticket的AuthorizationData字段中，但是很巧妙可以利用KRB_TGS_REP消息的生成的逻辑构造出来。KRB_TGS_REP::Ticket::EncryptedData的生成会把KRB_TGS_REQ::enc-authorization-data填充进去，KRB_TGS_REQ::enc-authorization-data是我们客户端可控的，而KRB_TGS_REP::Ticket是用服务账户的哈希进行加密的，所以我们需要把KRB_TGS_REQ::sname设置为krbtgt账户，这样我们就可以把构造好的PAC填充到被krbtgt加密的Ticket的AuthorizationData字段中了。
（1）RPC 编程文档：https://learn.microsoft.com/zh-cn/windows/win32/rpc/rpc-start-page
https://jlajara.gitlab.io/Potatoes_Windows_Privesc
（1）WinRM 协议文档：https://learn.microsoft.com/zh-cn/windows/win32/winrm/portal
（1）WMI 协议文档：https://learn.microsoft.com/zh-cn/windows/win32/wmisdk/wmi-start-page
（1）概念验证
（2）Zerologon 漏洞原理
Netlogon 协议是一种 RPC 接口，Netlogon 协议提供的方法有两类，一类是需要经过 Netlogon 协议身份认证过后才可调用的方法，一类是不需要经过 Netlogon 协议身份认证即可调用的方法。而 Netlogon 协议身份认证可以根据协商标志选择身份认证过程中计算凭证时使用的算法，而其中的算法之一 AES_CFB8 存在缺陷，结合 Netlogon 协议的认证过程可以绕过 Netlogon 协议的身份认证，导致可以在没有凭据的情况下调用 Netlogon 协议的所有方法。
（3）攻击路径
- 利用 AES_CFB8 算法缺陷绕过 Netlogon 协议的身份认证
- 身份认证后调用 Netlogon 协议的
NetrServerPasswordSet2方法重置域控机器账户的密码为空 - 使用空密码进行 Dcsync
- 恢复域控的密码防止域控脱离域
（4）注意到的细节
- 在完成 Netlogon 协议的身份认证之后，调用
NetrServerPasswordSet2方法需要传递Authenticator参数，Authenticator参数在服务器即域控还会进行一个验证，这个验证也是通过 AES_CFB8 缺陷进行绕过。 - 调用
NetrServerPasswordSet2方法需要在ClearNewPassword参数传递加密的新密码，加密使用 AES_CFB8 算法导致可以在不知道加密密钥的情况下构造空密码的密文。 - Netlogon 协议身份认证后的通信默认是经过签名的，通过协商标志可以使身份认证后的通信不需要经过签名，所以概念验证设置协商标志为
0x212fffff - AES_CFB8 算法缺陷利用成功有概率性，尝试两千次可以达到99.96%概率
（5）重置域控机器账户密码为空后需要及时恢复域控密码以避免域控脱离域，原因是活动目录存储的域控机器密码和本机lsass进程存储的域控机器密码不一样导致的。
（6）恢复域控密码的手法
（8）修复方案
（9）日志特征
（10）链接博文/文档
- https://learn.microsoft.com/zh-cn/openspecs/windows_protocols/ms-nrpc/ff8f970f-3e37-40f7-bd4b-af7336e4792f
- https://www.anquanke.com/post/id/219374
- https://blog.csdn.net/systemino/article/details/109017593
（1）概念验证
漏洞允许机器账户的名称（名称由sAMAccountName属性标识）不以 $ 符号结尾
在进行 S4U2self 请求时如果没找到 TGT 票据标识的机器账户，则会在机器账户后加上 $ 符号再进行查找
（4）sAMAccountName spoofing 漏洞原理
sAMAccountName spoofing 漏洞是由 CVE-2021-42278 和 CVE-2021-42287 漏洞组成的一条攻击路径。使用 CVE-2021-42278 漏洞我们可以创建一个机器账户且对这个机器账户的sAMAccountName属性和serviceprincipalname属性有写权限。通过对机器账户的sAMAccountName属性修改为域控机器账户去除$符号然后使用修改过后的机器账户通过 AS_REQ 请求 TGT 票据。请求完 TGT 票据后再修改机器账户的sAMAccountName属性为任意值之后使用 S4U2self 请求 ST 票据。在KDC处理 S4U2self 请求时根据 TGT 票据标识的机器账户进行查找用户，此时由于我们的机器账户已经更改掉sAMAccountName属性了导致没查找到对应用户，这时候KDC会在机器账户后加上 $ 再进行查找，此时查找到的是域控的机器账户，然后KDC用域控的机器账户哈希生成 ST 票据，此时这个 ST 票据是可以用于模拟特定客户端针对域控特定服务进行请求的。
（5）攻击路径
- 使用 CVE-2021-42278 漏洞我们可以创建一个机器账户
- 清除新创建的机器账户的
serviceprincipalname属性（这是由于在修改sAMAccountName属性时会同步更新serviceprincipalname属性导致和域控的serviceprincipalname属性冲突，通过清除机器账户的serviceprincipalname属性来避免） - 通过 LDAP 协议修改创建的机器账户的
sAMAccountName属性值为域控机器账户的sAMAccountName属性去掉$符号 - 通过 AS_REQ 请求 TGT 票据
- 通过 LDAP 协议修改创建的机器账户的
sAMAccountName属性为任意值 - 通过 S4U2self 请求域控的机器账户哈希生成的 ST 票据
（6）概念验证中的扫描漏洞是否存在模块是如何工作的呢
通过能否成功请求不携带 PAC 的 TGT 票据来判断，在 CVE-2021-42287 漏洞的修复中可以知道它的原理。在安装 CVE-2021-42287 补丁后不允许请求不携带 PAC 的 TGT 票据。
这里的扫描只是判断了是否安装 CVE-2021-42287 补丁而没有判断是否安装 CVE-2021-42278 补丁
（7）修复方案
-
安装 CVE-2021-42287 补丁和 CVE-2021-42278 补丁，在安装了 CVE-2021-42278 补丁之后由普通域用户创建的机器账户的
sAMAccountName属性需要以$结尾
-
将 Machine Account Quota 设置为0以阻止普通域用户创建机器账户或者修改SeMachineAccountPrivilege特权的权限（从SeMachineAccountPrivilege中删除Authenticated Users并添加Domain Admins或另一组允许的帐户）
（8）日志特征
（9）链接博文/文档
（1）概念验证
（2）CVE-2022-26923 漏洞原理
使用 Machine 模板向 AC 申请证书时 AC 会把请求者的 dNSHostName 属性嵌入到生成的证书中，使用生成的证书请求 TGT 票据时 KDC 会从证书取出镶嵌的 dNSHostName 属性值并查找 sAMAccountName 属性值和取出值匹配的账户，最后使用查找到的账户完成 TGT 票据生成。通过把机器账户的 dNSHostName 属性设置为 DC 的 dNSHostName 属性值可以达到伪造 DC 的效果。
（3）攻击路径
- 使用普通域账户创建一个机器账户，普通域用户对创建的机器账户有
dNSHostName属性和serviceprincipalname属性的写权限 - 通过 LDAP 协议修改机器账户的
dNSHostName属性为 DC 的dNSHostName属性值，修改dNSHostName属性时会同时修改serviceprincipalname属性值，因为serviceprincipalname属性值引用了dNSHostName属性值，所以需要清除serviceprincipalname属性值或者删去serviceprincipalname属性值中引用dNSHostName属性的部分 - 使用 Machine 模板向 AC 申请证书
- 使用申请的证书请求 TGT 票据，生成的票据标识的是 DC 机器账户
（4）为什么在攻击路径的第四步中不需要先更改dNSHostName 属性值再请求 TGT 票据？这是因为在使用证书申请 TGT 票据时 KDC 会从证书取出镶嵌的 dNSHostName 属性值并查找 sAMAccountName 属性值和取出值匹配的账户，最后使用查找到的账户完成 TGT 票据生成，所以机器账户的dNSHostName 属性值对 TGT 票据生成并没有影响，机器账户的dNSHostName 属性值只在证书请求阶段产生作用。
（5）修复方案
-
在 ADCS 和 域控 上安装 CVE-2022-26923 补丁，补丁通过在证书中添加 对象标识符 (OID) (1.3.6.1.4.1.311.25.2) 进一步对用户进行识别，防止通过
dNSHostName属性值进行欺骗。
-
通过将 Machine Account Quota 设置为0或者修改SeMachineAccountPrivilege特权的权限禁止普通域账户创建机器账户来阻断攻击路径，但这会有一定的绕过风险。
（6）日志特征
（7）链接博文/文档
- https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4
- https://posts.specterops.io/certified-pre-owned-d95910965cd2
https://www.anquanke.com/post/id/216808
https://github.com/hfiref0x/UACME
无文件bypassUAC：https://enigma0x3.net/2016/08/15/fileless-uac-bypass-using-eventvwr-exe-and-registry-hijacking/
（1）PsExec 概念验证
（2）PsExec 攻击路径
- 连接服务器 SMB 服务
- 通过 SMB 服务上传 PSEXESVC.exe 文件到服务器
- 连接服务器的服务控制管理器
- 通过服务控制管理器创建一个执行文件为 PSEXESVC.exe 的服务并启动服务
- 客户端通过管道/其它方式和服务器上新创建的服务通信来管理远程计算机
- 删除服务器上新创建的服务
- 删除服务器上的 PSEXESVC.exe 文件
（3）PsExec 通信数据包
（4）特征日志
（5）AtExec 概念验证
（6）AtExec 攻击路径
（7）AtExec 通信数据包
（8）特征日志
（9）SmbExec 概念验证
（10）SmbExec 攻击路径
- 通过 MS-TSCH协议 协议在远程服务器上创建计划任务并执行，计划任务内容为
C:\Windows\system32\cmd.exe /Q /c echo notepad.exe ^> \\127.0.0.1\C$\__output 2^>^&1 > C:\Windows\TEMP\execute.bat & C:\Windows\system32\cmd.exe /Q /c C:\Windows\TEMP\execute.bat & del C:\Windows\TEMP\execute.bat，计划任务的作用是创建一个 execute.bat 批处理文件并执行它，execute.bat 文件的内容为notepad.exe > \\127.0.0.1\C$\__output 2>&1 - 删除创建的计划任务
- 通过 SMB 协议读取
C$\__output文件获取命令执行结果 - 删除
C$\__output文件
（11）SmbExec 通信数据包
（12）特征日志
（13）DcomExec 概念验证
（14）DcomExec 攻击路径
- 获取远程服务器 ShellWindows/ShellBrowserWindow/MMC20 DCOM对象
- 调用 ShellWindows::ShellExecute、ShellBrowserWindow::ShellExecute、MMC20::ExecuteShellCommand 方法执行系统命令并把命令结果重定向到文件中
- 通过 SMB 服务读取文件内容获取命令执行结果
- 删除文件
（15）DcomExec 通信数据包
（16）特征日志
（17）WmiExec 概念验证
（18）WmiExec 攻击路径
- 连接远程服务器上的 WMI 服务并获取远程服务器的
Win32_Process对象 - 调用远程服务器上
Win32_Process对象的Create方法执行命令，命令内容为cmd.exe /Q /c whoami 1> \\127.0.0.1\ADMIN$\__1683292860.218341 2>&1 - 通过 SMB 服务读取文件内容获取命令执行结果
- 删除保存命令结果的文件
（19）WmiExec 通信数据包
（20）特征日志
https://github.com/api0cradle/UltimateAppLockerByPassList
https://www.anquanke.com/post/id/159892
- Microsoft Kerberos (Windows)
- [MS-KILE]： Kerberos 协议扩展
- [MS-SFU]：Kerberos 协议扩展：用户服务和约束委派协议规范
- Kerberos SSP/AP (Windows)
- 适用于 Windows Vista 的 Kerberos 增强功能
- Windows 7 的 Kerberos 身份验证更改
- Kerberos 身份验证技术参考
详细看 用户服务和约束委派协议规范，细节比较多（反复翻阅
关于委派类攻击参考这篇文章，比较全面的
微软在非约束委派的实现上使用的是 带有转发的票证授予票证 (TGT)的 Kerberos 委派 机制，流程图在这里的图一
约束委派委派的哪个服务不重要，因为服务在整个 Ticket 结构中位于未加密部分，直接修改即可
S4U2-Self 协议也就是协议转换
寻找以机器账户发起认证的原语以拼接资源委派攻击链
- 微软不认的“0day”之域内本地提权-烂番茄（Rotten Tomato）
- NTLM反射添加 msDS-AllowedToActOnBehalfOfOtherIdentity
遇到问题查阅 用户服务和约束委派协议规范，反复翻阅