本章處理的是一次影響一個帳號的接管事件：有人來說自己登不進去、或說有人用他的身分做了事，也可能是系統先偵測到異常。

它與 7.37 密碼外洩之後 是同一類事件的兩端。那一章的範圍涵蓋大量帳號而判不出是哪些，這一章的範圍是一個帳號、明確得多，而困難換到另一個位置：站在對面的那個人是不是帳號的主人，本身要先判。

本章涵蓋與不涵蓋

本章聚焦事件發生之後的處置與核身。密碼重設流程本身怎麼設計（那是攻擊者最常走的路，也是這一章多數失敗的來源）在 7.42 密碼重設流程。大量帳號的分層範圍與法規通報在 7.37。登入端點本身的異常判讀與節奏（連續失敗、地理切換、不尋常時段）在 7.2 終端使用者的登入節奏。客服代替使用者操作的授權設計在 7.2 代理操作的授權邊界——本章用它的結論、不重複它的推導。這件事要不要當事故啟動走 8.1 事故分級與啟動條件。

判讀軸：求助的人是誰本身待證

多數事故的處置從「發生了什麼」開始，而這一類要先回答另一個問題：現在跟我說話的這個人，是帳號的主人還是接管它的人。

兩種人的說詞幾乎一樣。真正的使用者登不進去，因為攻擊者改了密碼；攻擊者想接管一個他還沒完全控制的帳號，最短的路徑就是宣稱自己登不進去。兩者都會說「這是我的帳號、我進不去、請幫我」，而處置的每一步都在移動帳號的控制權——把控制權交給錯的那一個，等於替攻擊者完成他做不到的最後一步。

這條軸有一個直接的推論：動作要按「會不會改變控制權」分兩類。撤銷會話、凍結高風險操作、記錄異常都不改變控制權，做錯了只是打擾使用者；改綁定信箱、重設密碼、移除既有的第二因子會改變控制權，做錯了就是把帳號送出去。前一類可以在核身完成之前就做，後一類不行。

事件從哪裡進來，證據強度不同

使用者主動回報是最弱的一端。他手上有什麼證據取決於他還剩多少存取權，而這正是待證的事。這一類要走完整核身。

系統偵測到的強度中等，而它的價值在於訊號來自自己這一側、不受回報者影響。可用的訊號包括同一帳號在短時間內出現地理上不可能的兩次登入、登入之後立刻修改聯絡方式或第二因子、以及從未見過的裝置完成登入後大量匯出資料。這一類可以在沒有任何人聯繫的情況下先做不改變控制權的那一類動作。

第三方通報（外洩清單的比對服務、支付方的爭議通知、另一個平台的安全團隊）強度取決於來源，而它的特點是資訊往往比自己的日誌完整。這一類要先驗證通報本身的真偽——通報管道本身會被冒用。

三種樣態的處置順序相同，差別在核身要走多重。

核身要求什麼

核身的判準是要求的證據，攻擊者拿不拿得到。這句話要逐項套用在每一種常見做法上，而多數做法在接管已經發生之後就失效了。

已綁定的信箱與手機號碼是最常用的，也是最先失效的——接管者的第一個動作通常就是改掉它們。要求「你註冊時填的信箱是什麼」比寄一封信過去好，因為前者問的是歷史事實、後者送到的是當前狀態。

預設問題與個人資料（生日、地址、最後四碼）在多數情境下已經不構成證據，理由是這些值在別處外洩過、或本來就查得到。它們的作用退化成「提高一點成本」，不能當成單一依據。

真正還站得住的是攻擊者不容易複製的歷史行為：最近幾筆交易的金額與時間、帳號建立的大致時間、綁定過但已經移除的裝置、曾經使用的服務項目。這一類的共同性質是它們存在自己的資料庫裡、而攻擊者只有帳號當前的視角。要注意的是接管者若已經在帳號裡待了一段時間，他看得到的歷史就變成他也能回答的問題——所以問的要是接管之前的事。

企業與高價值帳號可以走人工核身或線下管道，而那條路徑本身的授權設計走 7.2 代理操作的授權邊界：誰能發動、要不要理由與時窗、紀錄怎麼歸屬。

攻擊者留下什麼

這一節是這類事件最常被漏掉的一段：重設密碼不會移除攻擊者已經建立的持久存取。

接管一個帳號之後，攻擊者的下一步通常是讓自己不依賴那組密碼。常見的留置有幾種：新增一個自己控制的回復信箱或手機號碼、註冊一支自己的第二因子裝置或憑證、產生一組長效的存取權杖或應用程式密碼、在信箱服務裡加一條轉發規則、以及授權一個第三方應用取得存取權。

這些的共同性質是它們在密碼重設之後仍然有效，而使用者這一側看不到——他只看到自己重新登入成功了。處置因此要包含一次逐項的還原，而能不能還原取決於這些設定有沒有留下變更紀錄，見 7.7 稽核追蹤與責任邊界。查不到變更紀錄時，退而求其次的做法是把所有這一類設定重置到預設值，代價是使用者原本正當的設定也一併消失。

判讀流程

  1. 先做不改變控制權的動作，不等核身：撤銷該帳號的全部會話、凍結高風險操作（改綁定、匯出、金流）、把該帳號的後續事件加上標記。這一步做過頭的代價只是使用者重新登入一次。
  2. 判斷事件從哪裡進來，據此決定核身要走多重。系統偵測到的可以先動；使用者回報與第三方通報要先驗證來源。
  3. 核身，判準是「要求的證據，攻擊者拿不拿得到」。要問接管之前的事。
  4. 核身完成之後才做改變控制權的動作，順序是先移除攻擊者的持久存取、再交還控制權。順序反過來的話，使用者會拿回一個仍然開著後門的帳號。
  5. 逐項還原攻擊者留下的留置：回復信箱與手機、第二因子裝置與憑證、長效權杖與應用程式密碼、轉發規則、第三方授權。
  6. 判斷這件事要不要升級。同一段時間內出現多起同型事件時，它不再是單一帳號的問題——那是 7.37 的範圍，判定門檻走 8.1 事故分級與啟動條件。
  7. 把這一次的訊號回寫到偵測面：這次是靠什麼發現的、有沒有更早的訊號當時沒有觸發，見 7.13 偵測覆蓋率與訊號治理。

這個決定失敗時長什麼樣

客服在一小時內處理了三十七個案件，其中一個是這樣：來電者說手機換號、收不到驗證簡訊，要求改綁定號碼。他答得出姓名、生日與地址，也說得出最近一次消費的大概金額。流程允許在這幾項都對的情況下改綁定，於是改了。

那些答案都在半年前另一個服務的外洩資料裡，而最近一次消費是他在帳號裡看到的——他兩天前就用外洩的密碼登入過一次，只是沒有做任何會觸發告警的動作。改完綁定號碼之後，他走正常的重設流程拿到了密碼。

沒有人發現的原因是這通電話的每一步都符合流程，而流程的核身項目訂在「一般人答得出、外人答不出」這個假設上。那個假設在資料外洩成為常態之後已經不成立，而它沒有被重新評估過——因為它從來沒有失敗得夠明顯。真正的使用者三週後才發現，那時攻擊者已經把回復信箱也換掉了。

常見風險邊界

  • 核身要求的項目列得出來，而沒有人給得出「攻擊者拿不到這幾項」的理由時，那套核身的實際強度未經評估。
  • 重設密碼被當成處置的終點時，攻擊者建立的持久存取全部留著，而使用者以為事情結束了。
  • 改變控制權的動作與不改變控制權的動作沒有分開時，處置只能等核身完成才開始，而那段等待期間攻擊者仍在帳號裡。
  • 客服流程的核身項目與自助流程不一致時，攻擊者會走比較鬆的那一條，而兩條路徑的維護者通常不是同一個人。
  • 同型事件的計數沒有人在看時，一批接管會被當成一批獨立的個案處理，而它們的共同成因不會浮現。
  • 攻擊者留置的設定沒有變更紀錄時，還原只能靠全部重置，而那會連使用者正當的設定一起清掉——這一項的成本在事件當下才會被發現。

下一步路由