0x00 前言

之前做的一個實戰(zhàn)項目，共耗時三個月，我參與了從開始的信息收集到最后數(shù)據(jù)分析的全流程。期間遇到并克服了許多困難與波折，其過程在此記錄并分享給大家。

項目特點：

1、目標以正常的生產(chǎn)狀態(tài)參與項目，沒有事先準備。

2、攻擊過程不限制路徑和手段。

3、以拿到目標的數(shù)據(jù)和人員身份為目的。

4、幾乎無時間限制，比速度和權限更重要的要求是穩(wěn)。

0x01 外部打點+撕開口子

一開始拿到的是目標的公司名和官網(wǎng)的url，除此之外沒有其他信息。自然首先要進行的步驟是踩點——信息收集。

經(jīng)過幾天的信息收集，我大概了解的目標的基本情況：公網(wǎng)上能訪問到目標的生產(chǎn)環(huán)境和測試環(huán)境，目標有幾個app都是套殼的，本質是調用了web端的api接口。

（1）生產(chǎn)環(huán)境：均部署在阿里云，收集到幾個后臺，一個官網(wǎng)，一些app的api接口域名（直接訪問是403，404），每個資產(chǎn)有單獨的外網(wǎng)ip地址。

（2）測試環(huán)境：和生產(chǎn)環(huán)境基本一樣的資產(chǎn)，只不過都部署在同一個ip上，通過不同域名來反向代理，不是云服務器，后面發(fā)現(xiàn)是目標自建的機房。

（3）人員信息：從目標官網(wǎng)的新聞動態(tài)和招聘網(wǎng)站上，收集到公司大體的人員架構——姓名，職位，部門。

外部信息收集的差不多的時候，就順其自然的可以打入目標內網(wǎng)了。之前發(fā)現(xiàn)目標測試環(huán)境都在同一個ip，掃該ip的全端口，在9999端口上發(fā)現(xiàn)一個xxl-job分布式任務調度平臺，xxl-job的作用大概是能遠程控制很多機器定期自動執(zhí)行某些任務，這些被控制的機器稱為執(zhí)行器。

用默認口令 admin/123456 進入xxl-job后臺，后臺可以添加GLUE(SHELL)計劃任務，但這個感覺是廢棄或測試的資產(chǎn)，里面只有一個執(zhí)行器還是它自己。

通過后臺添加計劃任務反彈shell，拿下目標內網(wǎng)一臺linux服務器，普通用戶權限。首先沒有嘗試提權，提權exp有可能導致系統(tǒng)崩潰，只有一個入口的情況下要好好珍惜。

并且現(xiàn)在就算不提權也能做很多事情，在該機器上打nps隧道代理進入目標內網(wǎng)，雖然之前收集到目標應該是沒有安全團隊的，但還是因為剛進來不了解目標內網(wǎng)情況，沒有進行大規(guī)模掃描（慫）。

PS：我怎么通過前期信息收集判斷目標是否有安全團隊：

1、招聘網(wǎng)站和目標官網(wǎng)中沒發(fā)現(xiàn)安全部門的存在。

2、信息收集過程中除阿里云自帶的waf外，沒見到其他安全措施。

3、xxl-job默認口令都敢放到公網(wǎng)上。

當然判斷不可能說100%準確，我為了求穩(wěn)，打算用手工探測內網(wǎng)80端口——就是在瀏覽器手動輸入同網(wǎng)段的ip地址，從1-255……

0x02 誤入歧途+靈光一閃

255個沒有全部輸完，大概二十幾個之后，發(fā)現(xiàn)了內網(wǎng)的gitlab代碼倉庫，其開啟了注冊功能，注冊一個賬號登入，里面只有兩個項目，下載回來看了一遍沒什么價值。

轉變思路，收集開發(fā)人員的郵箱，去sgk查密碼，拿到了其中一人的手機號和通用密碼，然后社工撞庫，一系列流程過后，收集到了他大量的信息，并登入他的微博，看博文的小尾巴得知其手機品牌，最后登入他的對應品牌的手機云盤。

這種云盤登錄后是不能直接查看信息的，還需要手機驗證碼二次確認，但我手里有這個人的大量信息，直接套路客服更改綁定手機號獲取到訪問權限，不過里面沒發(fā)現(xiàn)有用的東西。

一般這種情況我們稱之為：打偏了。

重新把重心轉回內網(wǎng)，感覺還是要從gitlab下手，之前里面沒什么東西可能是因為注冊的賬號權限不夠。

準備字典爆破gitlab其他用戶名，用戶名字典除了用收集的人名生成，還把前期收集到的域名也放了進入，最后發(fā)現(xiàn)其中一個域名作為用戶名存在，再爆破它的密碼就是簡單的域名+123。

爆破時使用針對目標信息生成的字典是很有必要的，之前我寫過一篇人名字典生成的腳本：《分享 | 人名字典生成腳本》

言歸正傳，用該賬號登入gitlab，果然發(fā)現(xiàn)了大量源碼，拖回來看了三天，收集到了內網(wǎng)的一個業(yè)務數(shù)據(jù)庫權限和大量redis權限，但是業(yè)務數(shù)據(jù)庫里的數(shù)據(jù)比較老，差了兩年多。

0x03 權限通殺+意外之喜

先放下數(shù)據(jù)庫不管，隨便挑了一臺redis，寫計劃任務getshell，發(fā)現(xiàn)是root權限。關于redis的getshell方法我之前也寫過一篇文章：

《實驗|CentOs下Redis漏洞利用方式復現(xiàn)》

在root用戶的.bash_history中發(fā)現(xiàn)明文口令，然后碰撞發(fā)現(xiàn)基本通殺了目標內網(wǎng)的所有l(wèi)inux服務器，不過不能登入生產(chǎn)環(huán)境的阿里云服務器。

用這個密碼在目標內網(wǎng)開始探測，基本流程應該是：登入linux服務器，看上面運行了什么東西，從數(shù)據(jù)庫中或配置文件中收集目標信息和用戶口令，然后帶著收集的信息再繼續(xù)碰撞下一臺……

當時做項目的時候沒什么經(jīng)驗，在目標內網(wǎng)數(shù)百臺服務器中迷失了方向，每登入一臺服務器都要看好久，把有用沒用的信息和文件都拖回來分析。如果換成現(xiàn)在，我會關注自己最終的目標是數(shù)據(jù)，收集的信息應該是明確的和數(shù)據(jù)庫相關的——應用配置，數(shù)據(jù)庫端口等，這樣效率會高一些。

當時我大概登了五六臺機器后沒什么大的收獲，這時突然想起來應該做一些權限維持了，目前權限維持就只是打了幾條隧道而已，如果被管理員發(fā)現(xiàn)直接ban了nps服務器的ip那權限一瞬間就全不見了。

通過咨詢身邊的大佬，我選擇了pam后門進行權限維持，pam后門：重新編譯并替換服務器上ssh連接鑒權所用的一個文件，之后便可以在不影響ssh正常使用的情況下用自己的后門密碼登錄服務器。

因為之前收集到目標外網(wǎng)的測試環(huán)境的ip是開了一個22端口的，所以選擇了這個方式，以便在內網(wǎng)權限丟失的時候能重新打入。直接用通殺的密碼連接這個端口，進到內網(wǎng)的又一臺機器上，在上面留下了pam后門。

這時順手又對這臺機器進行信息收集，意外的發(fā)現(xiàn)了一個運維腳本，里面記錄了內網(wǎng)另一個網(wǎng)段的一臺業(yè)務數(shù)據(jù)庫的ip和密碼，連接后發(fā)現(xiàn)雖然數(shù)據(jù)仍然不是實時在用的，但是很新，于是根據(jù)這個數(shù)據(jù)庫的連接情況反查到內網(wǎng)的核心后臺，在數(shù)據(jù)和源碼都在手的情況下開始向客戶交付。

0x04 未完待續(xù)

花費了三天時間對目標進行信息收集并打入內網(wǎng)，拿到了通殺內網(wǎng)服務器的口令，又發(fā)現(xiàn)了可以交付的數(shù)據(jù)，看似這個項目已經(jīng)快結束了，但其實這時才只過了一個月而已。在之后長達兩個月項目過程中，手里獲得的數(shù)據(jù)庫權限經(jīng)歷了三次波折——得而復失，失而復得。

中間甚至遇到了一次幾年不遇的突發(fā)情況導致內網(wǎng)權限盡失，并且驚動了目標運維人員。后面會記錄我如何和管理員斗智斗勇恢復并維持權限。

還有其他的問題：

1、怎么打入生產(chǎn)環(huán)境拿到最新的數(shù)據(jù)。

2、目標內網(wǎng)非域架構，如果非要不可，怎么拿到關鍵員工的個人機權限（財務，運維等）。

0x05 權限初掉+打怪升級

因為目標的系統(tǒng)和數(shù)據(jù)架構都很復雜，數(shù)據(jù)量也比較大，為了避免驚動目標，此時并沒有一次性把全部數(shù)據(jù)都拖回來（也是沒想到后面數(shù)據(jù)庫權限會掉）。

當時根據(jù)客戶要求先弄回了部分比較重要的表。然后自己就結合后臺功能對數(shù)據(jù)進行初步的屬性和用途判斷，是個很繁瑣的工作。

大概拿到數(shù)據(jù)庫的幾天后，在我對后臺做一些操作時，突然發(fā)現(xiàn)數(shù)據(jù)庫連不上了，再過幾分鐘發(fā)現(xiàn)后臺也沒了！ping 了一下數(shù)據(jù)庫和后臺應用兩臺服務器發(fā)現(xiàn)是關機了。當時嚇得我還以為是我把服務弄壞了，后面才得知目標這兩臺服務器就是會定期關閉的，極少部分時間才會開機做測試。

這是項目的第一次波折，沒了數(shù)據(jù)庫權限的我繼續(xù)在內網(wǎng)中漫無目的的飄蕩：登錄服務器收集信息，用瀏覽器查看占用端口的應用，了解源碼功能，批量掃端口……這個過程又持續(xù)了很久很久，過程中我對目標的系統(tǒng)和內網(wǎng)的了解逐步加深。

就像游戲里的打怪練級一樣，每一天的探測都會讓我增加很多經(jīng)驗值，終于經(jīng)驗值足夠的時候，就可以升級了——經(jīng)過N天的探測后，我摸清了內網(wǎng)的測試應用服務器的位置，同時發(fā)現(xiàn)他們中的大部分使用的是阿里云的rds數(shù)據(jù)庫。

即使從配置文件中獲得了賬號和密碼，rds數(shù)據(jù)庫也是遠程連接不上的，后面我自己去阿里云開了一臺數(shù)據(jù)庫，了解了一下基本配置后發(fā)現(xiàn)數(shù)據(jù)庫需要設置ip白名單后才可以對外網(wǎng)映射端口，但我當時也是掛著目標內網(wǎng)的代理去訪問的，怎么會受到白名單限制呢，這個問題卡了我?guī)滋鞄滓埂?/span>

突然在一個快下班的周五，也許是經(jīng)驗值夠了，我突然靈光一現(xiàn)的想到：即使是目標的內網(wǎng)，可能不同的網(wǎng)段，或者不同的服務器出口ip也是不一樣的。后面打進了目標的路由器才知道，能連通他們數(shù)據(jù)庫的出口ip只分配給了大概五臺服務器，驗證了我的想法。

不過當時沒有路由器的權限，并且已經(jīng)探測許久，士氣有些許低落，但我還是打起精神去嘗試了——登錄他們某臺應用服務器，新打了一條nps隧道，然后連接這條隧道再一次嘗試遠程連接阿里云數(shù)據(jù)庫。突然就成功了！數(shù)據(jù)雖然仍不是實時的，但是比之前那個還新。于是那個周五我搞到了晚上十一點才回家……

0x06 權限二掉+權限盡失

有了第一次的教訓，這次拿到數(shù)據(jù)庫后我?guī)缀跏邱R不停蹄的dump數(shù)據(jù)，果不其然，一個周末之后數(shù)據(jù)庫就又沒了。登錄內網(wǎng)的應用服務器看應用日志，發(fā)現(xiàn)它們自己也連不上了。

后面得知因為目標的生產(chǎn)環(huán)境不在內網(wǎng)，所以內網(wǎng)這些應用只有在產(chǎn)品更新之前才會短暫的連通數(shù)據(jù)庫進行測試，產(chǎn)品上線成功后內網(wǎng)這些應用就處于停滯狀態(tài)，開發(fā)人員平時用的是內網(wǎng)的另外一批應用，它們用的是內網(wǎng)中數(shù)據(jù)特別老的那幾臺數(shù)據(jù)庫，對我們沒什么價值。

不過這次對我的打擊并沒有第一次那么大，首先我差不多已經(jīng)dump下了70%的數(shù)據(jù)，其次做過GA項目的師傅應該清楚，此時已經(jīng)不再需要我去獲取權限了。大概一個流程的時間（兩周），我被客戶要求不要再驚動目標。

于是這段時間，我就安安靜靜的繼續(xù)探索目標的內網(wǎng)（只登錄服務器，不登錄應用）。不同于之前找數(shù)據(jù)的目的，這次的探索的重心是摸清目標組織架構、人員信息、源碼信息等等?，F(xiàn)在回想起來，其實還是一個簡單的打怪升級的過程。歲月靜好的這段時間讓我沒想到后面還會有一場和管理員纏斗的血雨腥風。

記得那是一個快下班的周一，突然我發(fā)現(xiàn)我在目標內網(wǎng)打的所有隧道全掉了！最開始用于打入內網(wǎng)的xxl-job也不見了，留了pam后門的外網(wǎng)22端口也不通了。當時還抱有一絲僥幸，因為我還在幾臺服務器上留了計劃任務后門——在每天上午的固定時間向我的vps反彈shell。于是我就按時下班了。

第二天上班，早早的登陸vps開啟監(jiān)聽，結果過了當初設定的時間還沒收到shell，這是我才遲鈍的感覺到事情有點不太對。又經(jīng)過一小時的確認，我終于站起來和老大說了一句：“XXX（目標名）的權限全沒了……”

雖然客戶那邊可以搞定數(shù)據(jù)的問題，但目標系統(tǒng)架構復雜，數(shù)據(jù)混亂，之后還是需要內網(wǎng)的一些權限的，不然很難搞定這個項目。

將近兩個月的探索，我對目標內網(wǎng)的熟悉程度都可以去面試他們的運維了，結果現(xiàn)在“啪”的一下就沒了，沮喪情緒是肯定有的，但滲透工作就是會這樣一波三折。能承受靈光一閃獲得權限的意外之喜，就要承受突然之間權限盡失的意外之痛。經(jīng)過一分鐘的冷靜之后，我重新開始了外部打點。

0x07 百折不撓+如影隨形

一天的打點一無所獲，下班后去食堂吃了頓飯，回到工位看著電腦，鬼使神差的進行今天的最后一次嘗試：再掃一次目標外網(wǎng)ip的全端口，結果發(fā)現(xiàn)那臺熟悉的xxl-job又出現(xiàn)了！同樣的默認密碼登入，十分小心又熟練的再次getshell，進到內網(wǎng)發(fā)現(xiàn)通殺密碼沒有改，趕快一條一條恢復了所有的隧道。

做完權限恢復的工作，開始翻看服務器各種日志了解權限丟失的原因，才知道自己遇到了幾年不遇的突發(fā)情況——目標內網(wǎng)所有的服務器都關機了一遍，直到一天之后的現(xiàn)在才重啟回來。眾所周知，服務器一般是不會關機的，之前探測內網(wǎng)的過程中我也看到目標的服務器已經(jīng)連續(xù)運行幾年了，所以打nps隧道時沒有考慮到這一點，是直接運行的，關機后就斷了。

得知原因的我又去多打了幾條隧道，不同以往的是這次的nps隧道是注冊成服務的方式運行，可以實現(xiàn)開機自啟的效果。同時去復查了一下之前留的計劃任務，發(fā)現(xiàn)還在，看來管理員并沒有發(fā)現(xiàn)我的存在。因為已經(jīng)搞到差不多晚上11點了，做完這些工作后我就下班回家了。

沒慶幸多久，第二天上班我發(fā)現(xiàn)隧道掉了一條，xxl-job又不見了。通過還在的隧道進入內網(wǎng)翻看服務器上管理員的history，發(fā)現(xiàn)管理員在某臺機器上發(fā)現(xiàn)了我留的計劃任務后門，采取了應急措施（關機）導致我的隧道斷了一條。

不過這個管理員并不是安全人員（上周文章判斷目標沒有安全人員），只是一個運維，對安全應急響應似乎了解的不多。

他只是一臺一臺的登陸檢查計劃任務，查到的就清除計劃任務并重啟，同時關閉了內網(wǎng)對外網(wǎng)的一切端口映射，其實并沒有發(fā)現(xiàn)我留的隧道。而且因為我每次登陸后日志清除的很徹底，他也不知道我到底干了什么，掌握了什么信息。我甚至可以和他登陸同一臺服務器而不被發(fā)現(xiàn)。

那一天，我就跟著管理員的步伐，維持了我全部的隧道不被斷掉，同時悄悄登陸他們的路由器，重新對外網(wǎng)映射出一個留了pam后門的22端口。計劃任務后門我沒再留了，因為這已經(jīng)是目標運維的排查范圍，重復留的話意義不大。

如果這個管理員不是運維，而是安全人員的話，我現(xiàn)在應該已經(jīng)涼了。但很可惜，這個管理員并沒對我造成太多麻煩，反而在這一次風波后幫助了我打入生產(chǎn)環(huán)境。

0x08 求求你招個安全吧

經(jīng)過一天的梳理，我列舉一下計劃任務后門被管理員發(fā)現(xiàn)后，管理員采取的措施：

1、關閉對外網(wǎng)的所有映射端口，但是沒再去檢查路由器，同時沒有關閉路由器自己的映射端口。

2、一臺一臺的排查計劃任務后門，但沒有排查到nps隧道的存在。

3、更改了部分服務器的ssh端口，但沒有改密碼，是的，一臺都沒改，還是通殺。（改端口能攔住黑客？）

4、使用ansiable工具輔助排查，這個工具具體是什么原理我不太了解，只知道運維把服務器的ssh賬號密碼寫在了一個文件里，讓工具去讀取，然后實現(xiàn)批量登陸執(zhí)行命令的目的。

5、文件記錄了生產(chǎn)環(huán)境的阿里云服務器的賬號密碼，通關！

就這樣，讓一個運維去做安全人員的工作的結果是：不但制止不了攻擊者，反而給攻擊者提供了更多的便利。只有安全人員才會真正的重視安全。

0x09 收尾工作

權限穩(wěn)穩(wěn)的留住了，之后沒再出什么差錯?？蛻裟沁叺牧鞒桃沧咄炅?，之后就進入了復雜枯燥的數(shù)據(jù)分析過程。最后再分享兩個tips和一件趣事吧：

Q1：運維人員只記錄了生產(chǎn)環(huán)境部分服務器的密碼（生產(chǎn)環(huán)境密碼非通殺），有一些沒有記錄密碼的服務器卻又需要登入，怎么辦？

A1：目標生產(chǎn)環(huán)境有一臺跳板機，運維人員通過這臺跳板機去ssh連接其他服務器，在這臺跳板機上留alias別名后門即可抓到ssh連接使用的密碼。

Q2：目標內網(wǎng)非域架構，但后期項目需要拿到目標財務人員辦公機上的文件，怎么通過服務器打入特定人員的個人機：

A2：登入目標生產(chǎn)環(huán)境的后臺，找一個只有財務人員可見的板塊，但是沒找到，只有一個板塊部分符合要求——所有財務人員和一個運維有權限可見，于是去生產(chǎn)環(huán)境數(shù)據(jù)庫把運維的權限改沒，就變成了只有財務人員可見。之后在這個版塊留xss水坑攻擊，引導訪問此板塊的人員下載木馬，成功釣上來一個財務，拿到了其個人機的文件。

3、趣事：我在探測內網(wǎng)時拿到了目標公司的攝像頭總控權限，可以直播觀看目標公司日常辦公、開會和員工摸魚的全過程。

0x0a 后記

歡迎關注小黑，以后會繼續(xù)給大家分享我在工作中的實戰(zhàn)經(jīng)歷~

如果我的分享對你有幫助，可以在下面贊賞鼓勵！

END.

喵，點個贊再走吧~