使用自訂 SQL 規則檢測休眠賬戶登入 - Security Center

本文詳細介紹了如何在Agentic SOC平台中，利用Log Service（SLS）的SQL查詢能力，構建自訂檢測規則，實現對休眠賬戶異常登入等安全事件的即時監測與警示。

背景與目標

目標情境：檢測休眠賬戶的異常登入。

實現思路：通過定時SQL查詢，對比使用者“近期登入”與“歷史登入基準”，找出在近期出現但歷史上長期未出現的使用者。

核心邏輯

檢測SQL主要分為以下三個部分：

定義“近期活動”：查詢最近20分鐘內發生的所有登入事件。
定義“歷史基準”：查詢在“近期活動”之前的一個較長時間段（過去24小時內，但不包括最近20分鐘）內，發生過主機登入的使用者。
進行比對：將“近期活動”與“歷史基準”進行關聯。如果一個使用者在“近期活動”中出現，但在“歷史基準”中找不到任何記錄，則認為該使用者的本次登入是異常的。

定義“近期活動”

(
  select
    user_id,
    src_ip,
    username,
    uuid,
    start_time
  from
    log
  where
    cast(start_time as bigint) >= cast(to_unixtime (current_timestamp) as bigint) - 20 * 60
    and cast(start_time as bigint) < cast(to_unixtime (current_timestamp) as bigint)
) a

文法解析：
- from log：從 log 表中查詢資料。
- to_unixtime(current_timestamp)：擷取目前時間的Unix時間戳記（秒）。
- cast(... as bigint)：將時間戳記轉換為長整型數字，便於進行數學運算和比較。
- where ...：定義了一個 20分鐘的滑動時間視窗，從目前時間點向前追溯。
  - >= ... - 20 * 60：日誌的開始時間（start_time）必須大於等於“目前時間 - 20分鐘”。
  - < ...：日誌的開始時間必須小於“目前時間”。
語義解析：
- 目的： 定義一個名為 a 的“近期活動”集合，用於圈定分析的主要對象。
- 結果： 一個臨時結果集，其中包含了在最近20分鐘內有過活動的使用者及其ID (user_id)、源IP (src_ip)等關鍵資訊。
- 關鍵點： “近期”被精確定義為從目前時間點向前追溯的 20分鐘 時間視窗。

定義“歷史基準”

(
  select
    user_id,
    username,
    uuid
  from
    log
  where
    schema='HOST_LOGIN_ACTIVITY' and
    cast(start_time as bigint) >= cast(to_unixtime (current_timestamp) as bigint) - 24 * 3600
    and cast(start_time as bigint) < cast(to_unixtime (current_timestamp) as bigint) - 20 * 60
) b

文法解析：
- schema='HOST_LOGIN_ACTIVITY'：明確指定只查詢主機登入活動相關的日誌，使歷史基準更精確。
- where ...：子句定義了一個從24小時前到20分鐘前的時間區間。
  - >= ... - 24 * 3600：日誌開始時間需大於等於“目前時間 - 24小時”。
  - < ... - 20 * 60：日誌開始時間需小於“目前時間 - 20分鐘”。
語義解析：
- 目的： 構建一個名為 b 的“歷史基準”集合，作為判斷近期活動是否異常的參照物。
- 結果： 一個臨時結果集，包含在過去一天內（但不包括最近20分鐘）有過登入活動的使用者。
- 關鍵點： 該時間視窗被設定為 從24小時前到20分鐘前，這確保了歷史基準與近期活動資料 沒有重疊，避免了自我比較的邏輯錯誤。

利用 `LEFT JOIN` 進行差異對比

... a
left join
... b on a.username = b.username and a.uuid = b.uuid and a.user_id = b.user_id

文法解析：
- LEFT JOIN：以左表（a，近期活躍使用者）為基準，將其每一條記錄與右表（b，歷史活躍使用者）進行匹配。
- on a.username = b.username and a.uuid = b.uuid and a.user_id=b.user_id：指定了關聯條件，通過username, uuid, user_id三個欄位來唯一識別一個使用者實體，確保匹配的精確性。
語義解析：
- 目的： 將“近期活動”(a)與“歷史基準”(b)進行關聯，嘗試為每個近期活動的使用者找到其對應的歷史登入記錄。
- 結果： 產生一個組合結果集，其中包含了a表的全部記錄，以及b表中能通過使用者身份欄位成功匹配上的記錄。
- 關鍵點： 利用 LEFT JOIN 的不對等特性：如果a表中的使用者在b表中 不存在，關聯後，所有屬於b表的欄位值將為 NULL。這是識別“新出現”行為的核心機制。

篩選最終結果

where
  (
    b.username is null
    or b.username = ''
  )

文法解析：
- b.username is null：利用 LEFT JOIN 特性的關鍵。當近期登入的使用者（在 a 表中）在歷史基準（b 表）中找不到任何登入記錄時，b.username 就會是 NULL。
- or b.username = ''：這是一個防禦性條件，用於處理某些情況下日誌欄位可能為空白字串''而不是NULL的情境。
語義解析：
- 目的： 從關聯後的結果中，精確篩選出那些“僅在近期出現，但在歷史基準中無記錄”的異常活動。
- 結果： 經過此步過濾，結果集中僅保留那些 LEFT JOIN 中未能匹配上的記錄，即真正關心的例外狀況事件。
- 關鍵點： b.username is null 是整個檢測邏輯的 核心決策點。它利用上一步產生的 NULL 值，將“近期有、歷史無”的記錄從海量資料中分離出來。

`SELECT DISTINCT`：輸出警示

select distinct
     a.user_id,
     a.src_ip,
     a.username,
     a.uuid

文法解析：
- SELECT DISTINCT：選擇並輸出指定的欄位，並對結果進行去重，確保對於同一次異常登入事件只產生一條警示。
語義解析：
- 目的： 整理並輸出最終的、可直接用於警示的例外狀況事件列表。
- 結果： 一個清晰、去重的警示清單，每條記錄都包含定位例外狀況事件所需的核心溯源資訊（如使用者ID、源IP等）。
- 關鍵點： DISTINCT 的使用至關重要。它能對結果進行去重，確保在檢測視窗內（20分鐘），同一個使用者的同一類異常行為只觸發 一次警示。

完整解決方案

最終SQL查詢語句

*|set session mode=scan;
select distinct
     a.user_id,
     a.src_ip,
     a.username,
     a.uuid
   from
     (
       select
         user_id,
         src_ip,
         username,
         uuid,
         start_time
       from
         log
       where
         cast(start_time as bigint) >= cast(to_unixtime (current_timestamp) as bigint) -20 * 60
         and cast(start_time as bigint) < cast(to_unixtime (current_timestamp) as bigint)
     ) a
     left join (
       select
         user_id,
         username,
         uuid
       from
         log
       where
         schema='HOST_LOGIN_ACTIVITY' and
         cast(start_time as bigint) >= cast(to_unixtime (current_timestamp) as bigint) - 24 * 3600
         and cast(start_time as bigint) < cast(to_unixtime (current_timestamp) as bigint) -20 * 60
     ) b on a.username = b.username
     and a.uuid = b.uuid
     and a.user_id=b.user_id
   where
     (
       b.username is null
       or b.username = ''
     )

在Agentic SOC中配置規則

購買並開通Agentic SOC
請參考購買並開通Agentic SOC文檔進行選購。建議同時選購日志接入流量和日誌儲存容量，以享受更完成的自訂威脅檢測服務。
登入控制台並進入建立自訂規則頁面
1. 登入Security Center控制台。
2. 在左側導覽列，選擇威脅分析與響應 > 规则管理。在控制台左上方，選擇需防護資產所在的地區：中國內地或非中國內地。
3. 在自訂頁簽，單擊新增自訂規則。

配置警示建置規則

在建立自訂規則面板，基礎資訊頁簽輸入規則名稱和描述後單擊下一步，進入警示產生設定頁面。

配置SQL檢測規則，配置參數可參考如下：

配置項	配置值
規則體	SQL
日誌範圍	登入日誌-主機登入成功日誌。
SQL查詢語句	複製SQL文法中的代碼即可。
調度間隔	固定間隔 - 20分鐘。
SQL時間視窗	24小時。
起始時間	規則啟用時。
產生結構	其他警示日誌。
警示類型	異常登入。
警示等級	中危。
ATT&CK階段	持久化 - T1136 Create Account。
實體映射	網路地址 `is_malware`： 1 `ip`： `$src_ip` `net_connect_dir`： in 主機 `is_asset`： 1 `uuid`： `$uuid`

配置事件建置規則
1. 在警示產生設定頁面，配置完成後單擊下一步，進入事件產生設定頁面。
2. 配置時間規則，配置參數可參考如下：
  - 建置事件：是。
  - 事件產生方式：同類彙總。
  - 彙總視窗：20分鐘。
驗證規則
新建立的規則為未啟用狀態，可對其進行測試，評估警示效果。測試時系統會自動校準警示欄位，請參考產生的校準建議，最佳化規則SQL或劇本，確保正式啟用後警示的準確性與規範性。
1. 將目標規則啟用狀態修改為測試中。
2. 在目標規則操作列，單擊查看警示測試結果。
3. 在測試結果詳情頁，查看測試產生的警示趨勢圖、警示列表。
4. 單擊目標警示操作列的詳情，查看警示的校準結果。
啟用自訂規則
測試通過後需在自訂規則啟用狀態列操作列修改狀態為啟用。
重要
建議參考下文，對規則進行測試後再啟用。

測試結果樣本

風險提示

誤判：長時間休假或出差後首次登入的正常使用者，可能被誤判。可通過延長dormant_hours閾值（如72小時）或配置使用者白名單來減少誤判。
漏報：日誌採集中斷或日誌欄位格式不規範，可能導致SQL無法正確計算時間間隔，造成漏報。需保障日誌資料的完整性和一致性。

SQL文法相關文檔

關於SQL文法的更多資訊，請參見SQL分析文法與功能。
如何配置威脅檢測規則，請參見規則管理。