17bdw
威脅情報收集之資產收集
從乙方威脅情報角度通過漏掃探測C2主機指紋,結合內部威脅情報做數據關聯,可以找出更多的樣本,分析樣本找到網絡特征和主機特征。而一套探測過程對於滲透測試來說來說往往提到的就是高危端口暴露,信息收集。
0x1 什么是漏洞掃描
- 漏洞掃描是完成風險評估的一種手段。很多專業者都搞出了很自動化、工程化的系統出來,從子域收集,ip 提取,字典定制化生成,新業務監控,威脅情報收集,漏洞掃描、告警,甚至自動生成報告,提交至 zdi、hackerOne 及各大 SRC 平台,實現技術套現……
- 威脅情報角度,一個C2可以掃描子域名、C段服務器端口、banner、證書幾個角度結合,在自研發監控系統中部署監控規則獲取更多樣本,找出攻擊事件。
0x2 為什么要做網段的探測
針對某些特定網段做同源確實會有威脅情報挖掘的價值。參考《那些和185.244.25.0/24網段有關的Botnet》
通過收集特定網段的端口信息結合當前掌握C2主機信息。資產收集的作用如下:
-
情報搜集:ip段搜索存活主機,域名、ip是否與apt組織活動有關聯
-
情報關聯:通過關聯的ip、域名開放的端口與掌握的數據進行匹配判斷C2主機實際作用
-
數據挖掘:通過內部威脅情報數據挖掘受控主機范圍、樣本數據
-
數據關聯:分析樣本,關聯樣本與主機的關系。入庫主機的遠程端口開放規則、已經掌握的遠控端口、端口banner、SSL證書。
0x3 資產收集
很多掃描器都可以做資產收集,通過大數據做收集的平台也開始增加起來。
但是這些平台多少會有查詢數量的限制。如果可以仿照一個技術信息庫,把資產按照標簽收集起來,每當出現一個漏洞就可以很容易檢索出特定標簽的網站了。
3.1 數據庫設計
為了測試,掃描的目標最初從幾個地方收集而來,中文網站總排名、補天、hackerone。從排名頂端的src大神常挖的目標摳出來關鍵字去百度搜索。最初覺得目標收集越多越好,還嘗試從被黑統計zone-h收集被黑過的站點。后來發現范圍太廣反而容易把自己淹沒,把原先目標給忘掉。
數據庫表設計頭疼了一段時間,以下是數據庫表設計的最初版。分別為目標站點表、二級域名搜集、IP、端口。
- 目標存儲表 target
存儲目標的數據,id主鍵,type標簽類型,domain或ip;創建時間和修改時間是為了關注目標狀態改變的時間。
id int // 主鍵自增長ID
source varchar // 資產來源
yys varchar // 運營商
domain varchar // 運營商域名
ioc_domain varchar // ioc域名
ioc_ip varchar // ioc ip
dq varchar // 地區
type varchar // 保存的是IP還是domain
target varchar // 目標組織
create_time datetime // 創建時間
update_time datetime // 更新時間
- 子域名收集 result_siblings
存儲子域名數據
id int // 主鍵自增長ID
host varchar // ip做主要索引
title varchar // 網站標題
ip varchar // ip
domain varchar // 運營商域名
port varchar // 當前域名訪問的端口
country varchar // 國家代碼
province varchar // 省份
city varchar // 城市
country_name varchar // 國家名字
header varchar // 網絡回顯
cert varchar // 證書信息
isp varchar // ISP信息
as_number varchar
as_organization varchar
data_source varchar // 數據來源
app_name varchar // app指紋識別
create_time datetime // 創建時間
update_time datetime // 更新時間
- IP收集 result_ip
把域名中的IP提煉出來,批量掃描ip。
id int // 主鍵自增長ID
taskid int // 任務ID
create_time datetime // 創建時間
update_time datetime // 更新時間
domain varchar // 域名
address varchar // IP地址
is_up varchar // 存活狀態
os varchar // 操作系統版本
- 端口收集 result_ports
采用多任務掃描
id int // 主鍵自增長ID
taskid int // 任務ID
create_time datetime // 創建時間
update_time datetime // 更新時間
address varchar // IP地址
port int // IP開放的端口
service varchar // 服務
state varchar // 狀態
protocol varchar // 協議
scripts_results varchar // 腳本掃描結果
3.2 入庫整理
入庫整理是有一段進步的,最開始Excel做初始數據庫整理。
后來數據量增大改用MySQL,Python2的第三方庫是使用的MySQLdb。再然后棄用Python2改用Python3操作MySQL代碼全改選用PyMySQL。
0x4 漏洞掃描的影響
對於威脅情報收集來說一定不可避免會遇到如下問題。
4.1 網絡影響
請求網絡包的頻率、數量,對網絡和應用造成影響,交換機/路由器可能因此宕機,引發連鎖反應,QPS過高可能超出服務的性能極限,導致業務中斷;
4.2 異常處理影響
業務無法正確處理請求包里的特殊輸入,引發異常宕機,比如一個私有協議的服務也許只是碰巧監聽在了TCP 80端口,收到一個HTTP Get請求就直接掛了;
4.3 日志影響
請求公網的業務時,每一個URL的探測,都可能造成一個40x或者50x的錯誤日志。而業務的正常監控邏輯正是用Access Log里的狀態碼來進行的。不做任何處理的話,突然40x猛增,業務的SRE和RD必然要進行響應
0x5 探測安全問題
不同於執法機構,安全公司是沒有權力去入侵網站來獲取流量和服務器權限的。但是對於情報挖掘來說,不入侵不等同於不探測,必須要通過人肉挖掘和分析的方式判斷C2主機然后嘗試關聯攻擊事件,內部數據庫收集樣本。
-
對於APT組織,打草驚蛇
-
對於合法組織,業務受損害
-
對於安全公司,容易惹上不必要爭論
0x6 改進
信息探測對於威脅情報挖掘也是必要引入的手段之一,通過流量還原大量PE,通過PE結構獲取到C2,通過C2擴展信息。但是可以結合規則調整掃描策略。
-
變更計划: 掃描的時間、IP/URL/端口范圍、QPS、測試用例集(有DoS的測試用例選擇、有Delete/Update相關的資產選擇、有POST隱蔽接口的選擇)
-
變更風險評估:交換機路由器的流量和容量、業務的QPS、業務/網絡掛掉的最極端風險評估
-
變更知會:業務的管理者、RD、SRE、DBA、QA甚至網絡維護方、有關部門,是否知道上述所有關鍵信息,並授權同意進行掃描
-
回滾計划:如果出了問題,怎么最快速的停止掃描和恢復業務(有些動作要上面的變更知情范圍的關鍵干系人配合)
-
變更觀察:執行掃描的時候,判斷業務是否正常,判斷APT組織的警惕性,以便在出問題的第一時間響應;
-
變更總結:灰度執行過程中總結不到位的地方,在下一次工作中改進
參考
漏洞掃描的一些運營常識
https://zhuanlan.zhihu.com/p/85736793
資產收集
