拿到一個被駭客入侵過的靶機！需要找到駭客入侵的ip和三個flag
那就進行一次入侵排查吧！
檢查賬號
從影子檔案看，應該只有兩個使用者，而且密碼近期沒有被修改過，所以應該沒有新新增使用者
這裡看到root和wheel組都有特權，而我們發現wheel組中正好就是有defend使用者，這說明它可以使用sudo充當root
而且root和defend都可以用來遠端登入，所以駭客可能是使用root或者defend遠端登入的
檢查歷史命令
我們檢查一下使用者的歷史命令
首先檢查root的
看到了第一個flag{thisismybaby} 並且看到編輯了/etc/rc.d/rc.local
這個是用來配置啟動項的東西，看來駭客配置了啟動項後門來許可權維持 我們跟進看看有什麼
發現了第二個flag{kfcvme50}，而且這個啟動項就是建立一個檔案
並且我們查到了這個檔案建立時間是在3月18日晚上8點左右，這大概說明了駭客入侵的時間
溯源
從歷史記錄看駭客是登入了root賬戶，建立了一個啟動項，但是啟動項只是建立空檔案。沒有多餘的操作了，這條線索也就斷了，我們得換個方向。得去想想駭客是如何登入root的？
那麼我們就去看看日誌，之前跟進駭客建立啟動項檔案時在3月18 20：24，這大概能定位駭客登入的時間
果然，我們在/var/log/secure找到了駭客的登入，是透過SSH公私鑰匙的方式登入的
這樣說明駭客的ip是192.168.75.129
而且從SSH公鑰的建立時間看 私鑰就是登陸之前不久創造的
這裡又出現了一個新的問題，駭客既然不是弱口令爆破進來的，他是怎麼上傳SSH公鑰的呢？
這個就說明他是透過其他協議或者服務上傳的，在金鑰檔案中看到了redis，懷疑是redis未授權訪問上傳的公鑰
我們去檢視對應redis服務的日誌
確實是發現了駭客連線的記號，說明駭客利用redis上傳檔案
而且發現很多連結記錄，個人認為應該是作者在搭建靶場的時候測試的，因為服務不停的開關，開關，那麼順著這段時間找一找有哪些檔案被建立或修改過的？
利用find找到一些時間範圍內的檔案
最後在redis.conf中找到了flag{P@ssW0rd_redis}
看下修改時間
駭客是在19：53修改的，看看對應日誌有麼有記錄
果然找到了，這樣一切就都說的通了！整個攻擊流程大概如下：
- 未授權訪問Redis，修改redis.conf檔案留下flag1
- 透過Redis上傳公鑰檔案後 利用SSH遠端登入Root使用者
- 在/etc/rc.d/rc.local下建立自啟動指令碼，並留下flag2
- 直接在shell命令列中列印出flag3
