# 内网渗透思路探索 之新思路的探索与验证

Author: 乌云历史资料库 (@wooyun_archive)
Published: 2016-05-26T02:45:00Z
Canonical: https://wepostx.com/topics/274

> 乌云历史资料归档
>
> **原始作者：** vodu
> **原始编号：** superkieran-wooyundrops:1219
> **原始发布时间：** 2016-05-26 10:45
> **声明：内容仅用于技术研究和个人使用，版权归 wooyun.org。**

---

# 0x00 前言

在安全发展初期，企业和一些个人使用杀毒软件进行安全防护，如卡巴斯基，symantec等，安全人员使用免杀这项技术来对抗杀软的检查。现如今，安防软件采用各种手段来保护内网安全，如网络流量分析，软件行为分析，网络行为分析等，提高了内网的安全性。
同时在渗透过程中经常遇到一种内网结构，由数台mac，linux和windows个人机组成的混合内网，一种扁平化结构。

![原文图片](/media/2016/06/cef6ff0a5f7ceae0c1b372f759e1fcba)

windows域与扁平化网络结构对比图
这种扁平化的网络难以管理和维护。并且给安全测试人员带来了困扰。渗透这些网络，就不能使用传统域渗透思路，进入域，获取域管理员权限，控制域控。
去年Google宣布，放弃内外网结构，将所有网络当做外网对待。这种访问模式要求客户端是受控的设备，并且需要用户证书来访问。访问有通过认证服务器、访问代理以及单点登录等手段，由访问控制引擎统一管理，不同用户、不同资源有不同的访问权限控制，对于用户所处位置则没有要求。也就是说，无论用户在Google办公大楼、咖啡厅还是在家都是一样的访问方式，过去从外网访问需要的VPN已经被废弃。而所有员工到企业应用的连接都要进行加密，包括在办公大楼里面的访问。可以说，Google的这种模式已经彻底打破了内外网之别。（援引于http://www.freebuf.com/news/67346.html）
所以针对传统网络结构以及包括这种无内网的网络结构提出一种新的渗透思路，同时能对流量行为检测有一定的规避作用。受到google的启发，如果渗透也不再关注内外网结构，不再专注于内网渗透，把对于外网的思路完整的放在渗透中，自始至终，一直使用外网渗透方式，是否就能渗透特殊的网络并且能在一定程度上逃避网络行为检测。开始探索，提出一个完整的渗透方案
该方案就是把思路更多的放在网络基础设备上，如Router，Switch等基础网络设备。攻击方式，就像NSA的TAO系统一样，检查流量，控制流量，最后利用流量。

# 0x01 渗透初探

基于这样的渗透思路，开始尝试寻找试验目标。
关于试验用目标，有几点要求，首先是在一个工作组环境中，（其次）拥有较多的主机或者较大网络。经过不断寻找，成功渗透进一个满足我需求的内网。
目标是一个学校，渗透的过程比较平常，注入，上shell，反弹不成功，正向反弹，控制服务器，没有太多的亮点。

![原文图片](/media/2016/06/e727464465efd18cfcfab25e81ef364e)

![原文图片](/media/2016/06/89162b67dd7d2b26b7688ebebdbd7db2)

![原文图片](/media/2016/06/178249f09fda6a403ffece787bf1c963)

然后开始针对网络设备进行攻击。利用正向反弹工具，将我的kali接入了内网，定向攻击网关设备。利用snmp的弱口令，直接获取了三层交换的控制权限。
ipconfig ／all结果截图：

![原文图片](/media/2016/06/16ea04f97bd563c631a18dd74efb3bc0)

执行snmpwalk读取密码：

![原文图片](/media/2016/06/85e33b57f48fcc744bca0ca7d1ebb12a)

成功读取到密码

![原文图片](/media/2016/06/5538509a9ebc329defff7dec21a9eae5)

注：kali的snmpwalk 不能利用proxychains走socks5代理，攻击内网机器，暂不清楚原因。
这里需要多说一下，我并没有直接进行固件级别的EXP测试，因为在exploit-db上的路由器固件的远程命令执行exp并不多，有很多的exp并没有公开，并且由于自己没有构造EXP的能力，遂放弃通过EXP获取权限的思路。

# 0x02 收集分析网络基础信息

通过正向代理访问网关，成功telnet连接到设备：

![原文图片](/media/2016/06/e64ef873b79d325a127fc439ee1f5cee)

然后立即查看所有配置：

![原文图片](/media/2016/06/f21bf89cdb2312787ff6d5c07ce01212)

查看版本信息：

![原文图片](/media/2016/06/e4845897fcc0c79eb53503d678e1764e)

查看设备的IP地址：

![原文图片](/media/2016/06/e2169cf23ea27708c934bffedaa20f25)

查看活动主机：

![原文图片](/media/2016/06/90cb7ecd3fddb521eaddc185f4357d95)

获取完基本信息之后，进行简单分析，华为的9306，三层交换机，查看到的下辖的用户不多，只有160多个，可能不准确，因为该时间段为非办公生活时间段。然后梳理流量线路，朝着外网方向，继续探索，又获取一台ruijie ES2000GS的控制权限，之后的机器不允许访问，无法继续往下拓展，总结如下
华为的9306应该是一层楼的或者一栋楼的汇聚，ruijie ES2000GS应该是一栋楼或者一个小园区的出口，校园核心的双交换网络或者出口路由器都不能被telnet访问。之所以这样分析，因为在已经控制的机器上暂未发现任何一个公网IP地址；链接数、活跃主机数量都处于一个较低的量级；发现了nat的配置，但是并没有公网映射；所以只能这样简单的判断。

# 0x03 获取内网用户详细信息

为了获取这个详细信息，就必须要对内网流量进行分析，为了完成这个目的，需要在内网路由器，与公网的Ubuntu之间建立了一个隧道。在准备阶段，预备了以下几种隧道协议部署方案：
协议安全性PAT穿透
GRE不加密否
PPTP加密是
L2TP不加密是
IP-SEC加密否
L2TP over IPSEC加密是
由于已经控制的设备没有公网IP地址，没有控制实现NAT功能的网络出口设备，就必须选择能穿越PAT的隧道。所以就只能在L2TP ，L2TP over IPSEC，PPTP中选择一个，最终选择了L2TP。因为锐捷经过测试发现不支持PPTP时，L2TP over IPSEC配置建立隧道导致设备不稳定，可能是设备自身的原因，在本地模拟环境测试时正常。
准备配置L2TP隧道，在本地的模拟环境上进行了部署，都能连通。但是到了设备上，报错说不支持命令，并且virtual－ppp接口无法添加配置，至今未找到原因。最后直接图形化配置完成，锐捷提供了L2TP VPN的图形化配置界面，很简单。

![原文图片](/media/2016/06/cde01692a8f281bc906ab87ae27e6d53)

![原文图片](/media/2016/06/8083d27468b13083737f90e9912b9a9b)

![原文图片](/media/2016/06/65c306a7b50da75d33d65a8751b741aa)

![原文图片](/media/2016/06/4073b39b62ee919e8dad2bdafec6fa5f)

在想分析流量的时候，出现一个问题，原计划是使用ip flow，但是该协议是cisco私有协议，锐捷与华为都不支持，并且笔者对华为的IP STEAM不熟悉，没有很好的解决方案，在准备进行完整引导流量的准备时，发现锐捷的网关设备，可以生成流量报表。

![原文图片](/media/2016/06/20455926e299a7c592d926ae4382dd31)

![原文图片](/media/2016/06/d82be03b9065974308fe285f32516b4c)

对统计好的流量大概分析后，对内网的流量有了一个大概的认识，HTTPS流量占了日常网页流量的很大部分，并且发现了内网有较大规模部署360安全大礼包。

![原文图片](/media/2016/06/b7d1992d8d27e3182ec7168753350ce8)

然后定向劫持一些腾讯的http网页，利用小工具，将beef代码插入到网页中，进行基本信息的获取。由于较多网页为HTTPS，并没有完善方案，所以收集到的信息很少。
这里需要多说一句，我劫持流量的方式是利用MQC或者添加路由，进行抓取，引导流量。没有使用Switch端口镜像配置获取流量，像（http://drops.wooyun.org/tips/649）该文章说的方式。并且在这里最大程度的反对大家使用这种方案！因为在cisco，juniper和huawei设备上，端口镜像将会导致DST端口或者VLAN失去承载正常业务数据的功能。简单说就是，进行端口镜像配置，流量被镜像到的端口将不再具有正常通信功能。如果不是经过严密讨论设计之后得出的方案，还是劝大家别去考虑该方法。
然后利用一些能找到的一些EXP，进行挂马。开始没有上线的，将马换成powershell empire的exe之后，终于有了一台上线的。分析可能是由于EXP和木马没有进行免杀，并且机器上有安装360或者一些其它的杀软，直接导致EXP与木马被杀。
因为只是验证性的渗透，使用的木马和EXP全部是网上公开的，并且没有准备特定场景的定向钓鱼，所以只能获取个别机器的控制权限。但是如果经过一些准备，在完全控制了用户流量这种情景下，种马不会特别难。
之后我试图进行内网控制扩展，即尝试渗透本园区之外的机器。结果两台设备上没有运行任何路由协议，路由配置就一条默认路由指向出口，其他的路由都是本地直连路由。

![原文图片](/media/2016/06/cc02f6827a6ce358d480bce721105302)

之前准备的方案是进行路由协议的劫持，或者称为路由表的优化更为确切，就是利用协议特性，将我变成必经之路，获取内网其他区域的流量。该设计方案并不关心路由协议，不论是OSPF，EIGRP，RIPv2或者是混合网络，只要他和其他机器之间运行着某种路由协议，就能完成路由的劫持。很遗憾，这个环境中不能实地测试了。
在尝试进一步明确内网设备信息，进行了简单的tracert查找，进一步明确了网络链路结构。在扩展渗透的时候受阻，核心路由器只给我回复icmp的信息，不允许我访问其他的任何端口，对于这情况，目前没有有效的方案。
这是一种比较无奈的情况，应该也就是大家一直对Router或者Switch没啥兴趣的原因。这类设备，如果精心配置了安全，那么除了EXP外，其他的控制思路都会十分的艰难。在这台设备上没有尝试已经公开的EXP。因为针对核心设备，EXP会引起的崩溃可能会导致机器瘫痪，重启，产生巨大的影响。
到此，测试就告一段落，清理渗透痕迹撤出，并没有近一步尝试扩展控制。如果继续，进行一段时间的数据包监听等行为，一定能有所突破。

# 0x04 总结

最近一直在研究流量的引导，控制，利用，以适应于各种渗透环境。
所以这是我想到对抗这种环境特殊内网的方案，我认为可以使用这种思路，用在之前渗透的所有目标上，如果有逆向开发人员，漏洞人员的配合，渗透测试将会在内网中如鱼得水。
这种思路经过简单的变形，放大，会是一种极为方便的渗透思路，我这里举一例：
flag在一个内网的一台机器上，利用传统针对目标的渗透，无法获取到内网权限。然后该怎么办？
获取目标网络信息，所属IP地址，然后，攻陷该运营商。然后利用流量控制目标1，突然发现目标2也在该运营商范围下，顺势拿下目标2，以此类推，目标3，目标4.。。。。。。。
发现目标10不在该运营商范围内，利用BGP劫持公网路由信息。然后顺势扩展目标11，目标12.。。。。。。
该示例没有计算投入，并且需要大量的技术支持。但是收益一样客观。有人说BGP劫持被监控，实际上是，精心设计的BGP劫持，不会被发现，只是需要精心设计。
再结合实例，谈一下关于渗透行为的敏感性
由于该渗透是通过注入等操作进入内网，然后SNMP获取路由器权限，隧道并没有使用IPSEC加密，这三个步骤不可能逃过行为流量检测。
关于木马回连：
木马回连的地址，全部使用update.microsoft.com域名，在网络设备上，做通网该IP地址的流量进行定向劫持到VPS。将本地机器接入VPS，并且将VPN的IP地址设置为该域名解析的地址。这样就成功使得木马上线。
使用的是empire木马，他的的流量使用SSL加密。关于EMPIRE的上线时间，并没有做特别设置，因为方便测试。在已控的网关与用户个人机器上看到的只会是用户与 update.microsoft.com该域名地址的ssl通信。但是在最外层的路由器上可以看到通网VPS的流量。所以说只要规避之前所说的敏感点，该方案会具备较高的隐蔽性。
并且没有敏感的内网渗透行为，例如利用一个用户账户，登陆不该登陆的机器，访问不该访问的位置，打开不属于自己的文件夹。所有设备的发现没有靠扫描（第一步除外）。关于flag，只是通过捕获用户，检查用户访问位置，是否能访问flag文件夹。重复过程，直到抓到访问flag的用户。
所以如果木马等工具能不被安防设备或者软件查杀，该渗透方案具有较高隐蔽性。由于该内网中没有行为检测设备或者我没有控制到，不能进一步判断。在设计之初，就考虑到顶级安全行为检测设备。由于非开发，没有考虑在机器端防护的部分。
最后说下这个思路的弊端
如果没有一个很成熟的钓鱼等方案，例如下载exe时做302跳转；劫持安全部门网页，提供安全更新；Router与Switch没有配置漏洞可以利用。那么该思路极其依赖漏洞的使用，例如需要Router与Switch远程命令执行漏洞来控制网络设备；flash，浏览器等软件的本地命令执行漏洞。
需要操作路由器来对路由表进行优化与流量的引导，至少得对路由器，路由协议，交换机有深入或者较为深入的了解。
对HTTPS没有什么好的解决方案。
所以如果某个安全研究人员或者初级团队使用，会遇到较多的瓶颈。
但是如果你有一个，个人能力合适，人员方向覆盖较全的团队，你将会收到一些惊喜。
下一步，我将研究如何对抗这种方案。

## Replies