在攻防演練中遇到的一個“有馬蜂的蜜罐”

有趣的結論，請一路看到文章結尾

---

在前幾天的攻防演練中，我跟隊友的氣氛氛圍都很好，有說有笑，恐怕也是全場話最多、笑最多的隊伍了。

也是因為我們遇到了許多相當有趣的事情，其中之一能夠拿出來說的就是遇到一個可疑的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爆破攻擊

當然，我目前沒有任何證據可以證偽或證實這一假定，真實情況是不是這樣，我們也不得而知