网站设计类型百度seo排名优化助手
在攻防演练中遇到的一个“有马蜂的蜜罐”
有趣的结论，请一路看到文章结尾
在前几天的攻防演练中，我跟队友的气氛氛围都很好，有说有笑，恐怕也是全场话最多、笑最多的队伍了。
也是因为我们遇到了许多相当有趣的事情，其中之一能够拿出来说的就是遇到一个可疑的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爆破联合起来思考的时候，它的用意究竟是什么：
- 对方内网正在举行某些安全检测，但192.168.31.102原主已经下线了
- 对方内网的的组织，试图通过这个诱人的socks，攻击连接者内网的ssh服务
没错，我偏好的猜测正是第二点，目标组织正在持续监视nps、socks的连接情况，当发现有连接者时，它将会对连接者的内网进行渗透
假设这个猜想成立，那么也就是说192.168.31.102并不是目标组织内网，而是上一位“连接者”的内网，他正在遭受ssh爆破攻击
当然，我目前没有任何证据可以证伪或证实这一假定，真实情况是不是这样，我们也不得而知