在攻防演练中遇到的一个“有马蜂的蜜罐”

在攻防演练中遇到的一个“有马蜂的蜜罐”

有趣的结论，请一路看到文章结尾

---

在前几天的攻防演练中，我跟队友的气氛氛围都很好，有说有笑，恐怕也是全场话最多、笑最多的队伍了。

也是因为我们遇到了许多相当有趣的事情，其中之一能够拿出来说的就是遇到一个可疑的NPS。（虽然但是，，管它可不可疑、蜜不蜜罐，我们还是拿到了一百分的权限分（🤣））

NPS介绍

nps是一款轻量级、高性能、功能强大的内网穿透代理服务器。目前支持tcp、udp流量转发，可支持任何tcp、udp上层协议（访问内网网站、本地支付接口调试、ssh访问、远程桌面，内网dns解析等等……），此外还支持内网http代理、内网socks5代理、p2p等，并带有功能强大的web管理端。

发现它的存在 - 未授权访问漏洞

这个NPS web服务也是我的队友发现的，通过nday,伪造auth_key打了个未授权访问，有个burp的插件可以帮助我们保持长时间在线而不需要手动反复伪造，我们只需要抓包然后启用插件，后续的请求都会走插件自动帮我们做到auth_key伪造

然后我们就能成功顺利进入到后台，我们发现了它的一些原有的隧道配置，不过没啥用

中招

我的队友率先使用npc去连接nps，然后连接它的socks隧道尝试访问目标的内网，但是socks是连接成功了，但访问不到目标内网

随后队友让我前去研究，我通过npc连接后，再去连接socks一样如此，并且npc还伴随的警报

在第一眼看到这个警告的时候我就觉得相当不对劲，因为这个警报看起来是连接不到内网的ssh，很明显，这个请求不可能是我本机发起的

但秉着尝试的态度，我还是去尝试访问已知的内网资产

当然结果跟队友一致，无法访问到

发现不对劲 - 方向反了

经过大量尝试、wireshark流量分析

我发现我可以访问到我本机内网的服务。

我是如何发现的呢？

原因是我通过socks代理，访问127.0.0.1:8080，居然能访问到我本机的burp的8080端口。

于是我再通过socks访问我本机上的python http.server的端口，发现也可以访问到。

有了这些证据，加上npc连接时产生的警报，我能够得出结论：方向反了，当我们通过npc连接上nps，并使用socks代理时，并不是我们访问到目标的内网，而是目标能访问到我们的内网.

也是相当奇葩，虽然我在看到npc的警报时就已经有了这个怀疑，但在当时我没有掌握充足而有力的证据，拥有的信息也相当的少，所以无法确定。

但现在已经水落石出。

可疑的大量ssh连接？ - 改网卡，fake ssh捕获账号密码

虽然进入靶标内网的目标失败了，但我还是对这个可疑的ssh连接相当感兴趣，因为它是大量ssh连接

当时我萌生了一个想法，既然是对方访问到我们的内网，也说明了这个ssh连接的流量是从目标访问到我们这边来的。

但我内网并没有192.168.31.102。我想到了好办法，随便把我本机上的vm虚拟网卡的ip改了

果不其然，npc警报发生了变化，已经能找到本机了

那么现在只差ssh的问题，我们需要搭建ssh然后捕获它的登录账号密码

fake ssh，通过它，我们可以很轻松的在linux和windows上一秒钟跑fake ssh服务并捕获账号密码

一运行，我震惊了

大量不同的账号密码，很明显这是ssh爆破

结束 - 细思极恐

这个结果也是相当哈人，我们没有因此得到我们想得到的ssh凭据，反而发现了ssh爆破。但有一点令我们不明白的是，当我们把方向反了的socks和这个ssh爆破联合起来思考的时候，它的用意究竟是什么：

1. 对方内网正在举行某些安全检测，但192.168.31.102原主已经下线了
2. 对方内网的的组织，试图通过这个诱人的socks，攻击连接者内网的ssh服务

没错，我偏好的猜测正是第二点，目标组织正在持续监视nps、socks的连接情况，当发现有连接者时，它将会对连接者的内网进行渗透

假设这个猜想成立，那么也就是说192.168.31.102并不是目标组织内网，而是上一位“连接者”的内网，他正在遭受ssh爆破攻击

当然，我目前没有任何证据可以证伪或证实这一假定，真实情况是不是这样，我们也不得而知