渗透测试笔记:Windows权限提升

我站在学校恢弘气派的图书馆前，好奇地看着匆匆的人群，又怯怯地望望入口处刷卡的机器。是的，我没有身份卡，如何才能进去看一看呢？

......

我站在光滑的大理石铺砌的地板上，甚为自己的机智感到自豪。按动了前往8楼的电梯按钮，不一会儿电梯门开了，一位一脸严肃的西装男站在门口：“请出示您的身份卡。” 我慌慌张张地退入电梯间，不停地按动着1楼的按钮和关门键。在门闭合的那一瞬间，我看到西装男拿着笔在纸上记录着：”2016.9.21，不速之客擅闯，本层管理员阻止。”

......

现在我坐在10楼金馆长华丽的办公桌后面，漫不经心地转着手中的笔，突然响起了敲门声。“进来。”我得意地应到，刚刚8楼那位呆板的西装男站在我面前。“删掉今天的门禁记录。” “好，请问还有别的事吗？” “帮我从数据库取点东西。”

.......

省略号部分请各位脑补~

好了，我今天的渗透故事就依照这个故事讲起吧。

之前在给校园网内某站作测试时发现一个小小页面文件上传类型检测不足，于是上传文件getsHell，建立连接。

进入了图书馆，就要四处浏览一下了。

首先打开一个模拟cmd，键入whoami，这个命令根据字面意思很容易理解，看下自己是谁~

然后就是试下net命令是否存在了，net.exe是专门用来远程或本地管理windows系统的命令，包含网络、环境、用户、服务等方方面面。

net user ： 显示当前系统中注册的用户，回车后命令执行成功。

看到一个Guest用户，一个admin用户，以及一个test用户。whoami显示自己是admin用户,看来管理员是用admin这个用户来运行服务器的。

这是不是意味着我们已经拥有了很高的权限了呢？执行几个敏感度高一点的命令就知道了！

执行 net user Username Passwd /add 命令，在系统里增加一个用户会怎么样呢？

敲下回车后大概等了30秒钟，毫无反应。。可没反应并不等于远程执行命令失败，于是我满怀希望的再次执行net user ，看看系统有没有多加用户进来，结果还是如前图所示。

于是我开始揣测，admin账户的权限其实并不高，也许连administrators用户组成员都不是，因此才无法添加用户到系统中去的。我们知道，windows要添加一个用户到系统中至少也要是普通管理员级别。于是再利用net命令，将admin账户添加进administrators组！

这条命令返回的居然是: 用户admin已经在administrators组里面了。奇怪，身为管理员竟然不能够给系统增加一个

用户，这管理员难道被降权了？

尝试去访问了几个可能存在admin用户密码hash的文件位置，所得到的结果一律是:Permission Denied.

甚至C:\Windows文件夹也无法访问。我慢慢发觉，这个所谓的admin账户仅仅是被赋予了比guest账户高一点的权限而已，除了能访问jsp服务器范围内的一些文件，其他系统级的事物根本做不了。

可事实真的如此吗？

既然只靠一个内部cmd我无法扩大哪怕一点点自己的权限，那就来它个里应外合！

我启动nmap,扫描目标ip地址：

这里给网站运维人员点个赞。。封闭尽量多的端口，降低web服务器的运行权限都是在给机器的安全上一道道保险。只是苦了我这测试人员。。

手里只有一个admin账户，还属于系统管理员，虽然自身权限不大，但是如果能打开多几个端口总是有用的。

REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Terminal" "Server /v fDenyTSConnections /t REG_DWORD /d 00000000 /f

以上命令表示在注册表对应键值位置插入值，通过注册表直接开启3389端口。（3389即windows远程桌面端口）

这次指令被顺利执行了，看到值被顺利写入注册表，我打开nmap重新扫描服务器端口。

结果仍然只有80端口是开启的。

难道命令又没被执行？不，冷静下来分析了一下， 作为一台服务器，不可能只有80端口开放，作为数据库连接的1433,3306等端口至少应该是开放的，他们应该是被防火墙屏蔽了。

那就关闭防火墙。

执行了经典的netsh firewall指令，希望防火墙不要是别的什么防火墙。。指令响应了大约10秒钟，返回执行成功！

再次动用nmap扫描，结果如下：

可以看到许多服务都已经处于对外开启状态。（这样容易将系统服务暴露在不安全环境中，测试完后应重启防火墙。）

那么再回到net命令，注意到刚刚是无法添加用户了，可是根据权限高者操作权限低者不需要低权限者向高权限索要认证的理论，我应该可以随意修改和我平级或权限低于我的用户的密码。我把注意力放在了guest（来宾账户）上，执行:

net user guest newpasswd 

果不其然，命令成功执行。我迫不及待地启动rdesktop程序连接目标服务器的3389端口，键入了guest账户的用户名和密码。

晕，guest账户没有权限执行远程登录，又是权限！！

好吧，耐着性子，我再一次使用net 执行 net localgroup administrators guest /add

希望admin的权限能够将guest用户添加进用户组。

和创建新用户的命令一样，这个命令也失败了。

我紧接着尝试了类似的 net localgroup desktop-users guest /add ， 同样无功而返。

接着我又尝试 net start telnet，希望借此能开启telnet服务从而使用guest用户登录，失败。

在自己的电脑上尝试了类似环境下的net命令都是成功后，完全无法明白为什么添加用户这样的权限内操作会失败。

现在我只有一个admin用户的shell,所做的事情非常有限，但如果能添加一个用户，那么我将知道这个用户的密码，从而完成更多的操作。

问了问度娘，某些杀毒软件会阻止某些net命令的执行过程，急忙返回webshell，执行tasklist看了一下。

基本可以断定是360拦截了创建用户的命令，并且很有可能把这条申请写在了入侵日志中。

抱着不见长江心不死的心态，我执行 

taskkill /im ZhuDongFangYu.exe /f  意图强制终结360的主动防御进程，这样应该就能安心地添加用户了。

主动防御进程只是默默地弹出了一条：拒绝访问。

于是一切又回到了原点，我费了很大力气打开的端口，关闭了防火墙，修改了来宾账户密码，这一切都被360的主动防御终结了。不得不感叹，360是很厉害的。

既然回到了原点，那不妨尝试别的路走走看。

我把注意力集中到我所能访问的目标服务器上的文件上来。虽然我能够访问的目录只有区区几个自己所属的目录和各个盘的根目录，但是web服务器一定有它自己的配置文件，那里面可能包含了数据库访问密码，甚至是admin账户的登录口令。

访问文件目录：

我耐心地一点一点把后缀名为.jsp或.xml以及.ini之类的涉及服务器后端脚本的文件全部Download下来，放在了一个文件夹中。

然后写了一个递归遍历这个目录下所有文件的程序，这个程序改自当时我模仿流行勒索软件的递归加密目录下所有文件的模块。

我把它传到了Github上：点击打开链接

我把搜索关键词设定为：admin,password,passwd,jdbc,auth,login等等一共10个关键词。

设置并启动这个脚本大概10秒后，我看到了我想要的： 在一个xml文件中，存储着数据库sa账户密码。 （sa是sqlserver数据库的超级管理员）

我立刻登录一台windows2008服务器，打开sqlserver manager, 键入了sa账号、密码，登录成功。

功夫不负有心人，看来之前关闭防火墙是很关键的一步。

与数据库建立连接后，我无暇顾及有没有什么关键数据在库里面，因为我的目标是提升自己在目标服务器中的权限，要完成一件事，总要专一点不是么？

果断新建查询，输入

exec xp_cmdshell 'net localgroup administrators guest /add'

看到了吗，我就是对让来宾账户变管理员这件事念念不忘啊。

点击执行，卡了2-3秒后，返回了红色的字，no。。

createProcess失败，错误代码5.

通过这句话我首先可以判定，xp_cmdshell这个允许sqlserver调用cmd的存储过程是存在的，其次，在调用过程中一定是遇到了什么问题导致无法创建net进程。那么是什么问题呢，不出意外的话，又是权限了。打开数据库角色管理器看一下：

sa用户并不是以windows身份验证登入数据库系统的，而是sqlserver自己的验证系统，这意味着虽然sa账号的密码很复杂， 但是其权限更是低于admin用户的，想想看，即便是admin用户来了都不能填加用户进入管理组，一个更低权限的用户更是没有办法。

真是绝望。我无奈地假设管理员会不经意地将sa与admin账户设置为同一份密码使用，简单猜解了一下admin用户的口令，失败。

于是祭出第一个杀手锏：

EXEC master.dbo.xp_regwrite 'HKEY_LOCAL_MACHINE','SOFTWARE\Microsoft\Windows\currentversion\run','shell','REG_SZ','C:\windows\system32\cmd.exe /c net localgroup administrators guest /add'

之前admin不是能写注册表么，调用master库的xp_regwrite的存储过程，通过注册表再调用一个shell执行我的命令。

这次直接返回了成功查询！

Nice啊，就在我以为一切顺利，已经登顶成功的时候，我打开3389窗口，键入了guest来宾账户的信息。

又是和之前相同的提示，该用户未授权使用远程桌面！

任我多次尝试，总是返回查询成功，可实际上的确没有任何效果。

只能祭出第二道杀手锏：

exec master..xp_regwrite HKEY_LOCAL_MACHINE,SOFTWAREMicrosoftJet4.0Engines,SandBoxMode,REG_DWORD,1

调用regwrite使jet引擎进入沙盒模式，

select * from openrowset(microsoft.jet.oledb.4.0,;database=c:\windows\system32\ias\ias.mdb,select shell("cmd.exe /c net localgroup administrators guest /add"))

利用jet执行cmd命令。

这个方法寄希望于c:\windows\system32\ias\ias.mdb这个文件的存在。幸运的是这个文件的确存在于目标服务器上，不幸的是返回了红字。。jet引擎在当前模式下不支持分布式查询，意味着只能在localhost域上执行。

于是我理所当然地返回了webshell,执行osql命令。没想到这个时候cmd却让我输入admin用户的密码了！

根本没有机会登入sa账号。

于是绕了一大圈之后，再次回到原点。一切都没改变，我拥有的仅仅是admin账户的一个cmd访问权限以及一个来宾账户。

尽管尝试了这么多种提权组合，数据库的存储过程都用尽了，还是没能提升权限，不免使我感觉非常沮丧。

就这么算了吧。

即使我通过cmd上传了一段木马程序并执行，这也很难躲过服务器上360的那双眼，还有什么办法呢？还有什么办法？

对，问题就在360. 如果没有360，那么通过admin账户就可以直接提权了。可是360进程又无法杀死。

但是如果360进程是由admin账户开启的，那么我直接注销admin账户，你360还会存在么？不，不会了，360会停止服务！

晚上20：59分。

大脑里电光火石般闪过上述理论，虽然未经实验，但感觉是一个办法！于是我直截了当地在Webshell里敲入简单的一行命令：

logoff.

回车后，webshell居然自动退出了。我试图重新启动虚拟终端，却得到提示:connection refused!

对，服务器程序也是由admin用户启动的，随着admin用户进程的结束，他所启动的用户空间进程都退出了！

可与此同时，我也失掉了webshell的访问权限，没有权限，就没办法执行命令，怎么办？？

同时我也吃惊地发现，网站主页已然处于无法访问状态：

天哪，这已不仅仅是提权了，这是要玩大了的节奏。我必须想办法提权不说，还要重新启动网站web服务器进程才行。

否则网站管理员很快就会发现异常，而我所有的行为都被忠实地记录在服务器的日志文件中。

还好，我没有慌张，因为刚刚脑子已经很清晰地分析清楚了，现在既然360已经退出，那么sa账户是有可能执行成功命令的吧！
对，再试一下好了。
于是我再打开一个查询框，键入了 exec xp_cmdshell 'net localgroup administrators guest /add'
点击回车的一瞬间，执行成功。
于是抓紧时间，登录3389端口，键入guest账户后，一个崭新的服务器桌面出现在我眼前。看来这个来宾账户没有人使用过。我心想。
既然拥有了管理员权限，又没有了360碍事，剩下的就看我动作快不快了。我必须进入到已经停摆的admin账户中，恢复tomcat程序才行。于是我打开注册表编辑器，找到LOCAL_MACHINE中的SAM项，修改访问权限，得到如图：
从Names里面找到我的guest账号和admin账号的注册表信息，导出admin账号所对应的注册表信息，将guest账号的信息覆盖为admin账号的信息，我迅速的完成了这个替换账号的过程，然后开一个cmd执行:
net user guest /del 删除
随后双击导入注册表。
关闭远程桌面再用guest账户连接之后，桌面上多了好多文件与程序，我知道我已经成为了admin账户的主人了。接下来，赶紧找到tomcat的启动批处理并执行之，再访问网站主页时，一切都恢复了正常。
呼出cmd,清理了我留下的大量日志，退出sa账号，建立隐藏超级管理员。
对我这种菜的一笔的测试员来说，这种几乎不借助任何工具的权限提升真的是非常大的挑战。在期间遇到的诸多问题除了经验和大胆的想象以外基本无所凭借，故记录下整个过程，以便大家能从中汲取些有帮助的思路以及增强反提权的一些措施。
最后再说一句，网站的管理员还是不错的！抛开漏洞不说，反制提权方面已经做得非常不错，如果360不是以admin账户启动的，我基本不再有机会。

exec master..xp_regwrite HKEY_LOCAL_MACHINE,SOFTWAREMicrosoftJet4.0Engines,SandBoxMode,REG_DWORD,1