“據粉絲爆料，1月5日凌晨，X站公司內部郵件發了全員釣魚連結，多位同事中招，受騙金額總計8萬左右。從5日凌晨2點到下午1點IT才把釣魚郵件刪除完。內部沒有發全員郵件告知，導致不斷有人受騙。在員工接連受騙的情況下沒有第一時間通知全員。全員郵件也不發一個，一分錢賠償也沒有。”

而從該微博內容附件的圖片顯示，受害員工成立了“釣魚郵件受害者”群，目前群內有72人，有X站受騙員工諮詢相關部門HR得到的回覆是，建議同事自行報警。群內部分員工認為，“從企業郵箱發出來的郵件導致員工受騙，難道企業不應該承擔後續責任嗎？”更有員工稱“錢我沒追回來，但是做做樣子報案，說點啥也好呀。”、“但公司一點責任都不想付。”

我覺得這個Case挺有教育價值，拿來跟大家簡單分享一下，同時也給我們自己提出一個問題，如果是我們遭遇這種攻擊，我們的應急響應支撐模型是否足夠做到快速響應？我們不說高大上的所謂的應急預案，我們需要能落地實行，能幫助我們SOC工程師進行快速響應，快速定位的具體步驟提案。

針對SCF（Security Control Framework）框架下的應急響應步驟，我更傾向於SANS的這一套，即PICERL流程，針對X站的釣魚郵件，我們嘗試透過建模應對該釣魚郵件的應急響應流程。

建模之前，需要先針對性的提出一些問題，並圍繞該問題進行解決才有實際落地的意義：

1. 使用者郵箱，密碼洩露，洩露來源來自於其他釣魚郵件？
2. X站用的是Exchange Online，郵箱OWA登入有沒有MFA啟用？
3. 如果為第3方郵箱傳送，SPF/DKIM/DMARC怎麼繞過的？（不在本案討論範圍）
4. 郵件中含有繁體字眼，員工怎麼如此容易中招？有否定期做釣魚郵件安全意識培訓？
5. X站釣魚郵件檢測機制是否有最佳化的可能？
6. X站釣魚郵件應急處置是否有釣魚郵件上報途徑？
7. X站釣魚郵件刪除工作，持續了大約11個小時，是否有改善基礎？
8. X站針對惡意事件爆發情況，有沒有施行快速應急熔斷機制？

Identification，檢測

• 來自於SIEM監控平臺的其他關聯告警
• 來自於郵件伺服器平臺病毒，沙箱告警，含且不僅含HASH, IP以及域名等
• 來自於使用者的釣魚郵件通知

Analysis，分析

• 獲取受害者使用者郵箱
• 獲取受害者使用者名稱
• 獲取受害者主機名
• 獲取受害者網路連線資訊
• 獲取受害者主機程式資訊
• 獲取受害者瀏覽器訪問記錄
• 獲取釣魚郵件的域名信譽值分析
• 獲取釣魚郵件的附件以及URL的信譽值分析
• 獲取釣魚郵件的宏分析情況
• 獲取釣魚郵件的沙盒執行狀況以及截圖
• 獲取可疑受感染的其他使用者，包括收件人，轉發，回覆，點選以及相關聯的資料

Containment，控制

• 關閉攻擊向量，含且不僅含殺掉執行程式，殘留檔案，檔案控制程式碼等
• 限制網路連線，透過防火牆或者主機HIDS，進行埠限制，比如僅保留3389等埠作為調查取證備用
• 隔離主機，可透過終端控制系統，比如EDR等進行隔離阻斷
• 重置使用者密碼
• 重置使用者MFA
• 重啟，關機，PE啟動等

Eradication，消除

• Ban釣魚郵件所提供的可疑域名
• Ban釣魚郵件所提供的可疑連結
• Ban釣魚郵件所提供的附件雜湊
• Ban釣魚郵件在沙盒中所涉及到的C2伺服器IP地址
• 禁用使用者賬戶
• 遠端刪除伺服器上符合釣魚郵件涉及到的相關郵件
• 提交釣魚郵件相關IOC給安全供應商

Recovery，恢復

• 檢查受害者主機補丁更新情況
• 檢查受害者主機防病毒以及終端控制系統EDR的啟用情況
• 採用第3方防病毒程式執行全盤掃描
• 恢復使用者禁用賬號
• 恢復受限網路
• 重置映象
• 使用者安全意識培訓以及考核

Lesson Learned，反思

• 究竟發生了什麼，在什麼時候？
• 工作人員和管理層在處理事件時的表現如何？
• 什麼樣的資訊需要最快獲得？
• 是否採取了任何可能阻礙擴散的步驟或恢復行動？
• 下次發生類似事件時，工作人員和管理層會採取什麼不同的做法？
• 如何改進與其他部門的資訊共享？是否有通用釣魚郵件上報渠道？
• 哪些糾正措施可以防止未來發生類似事件？
• 今後應注意哪些前兆或指標以發現類似事件？
• 需要哪些額外的工具或資源來檢測、分析和緩解未來的事件？
• 是否遵循了規定的標準程式？ 是否足夠？
• 是否能自動化應急響應流程，從而能更快速的處置以及應對危害。

具體施行步驟我就不再贅述，每個企業的安全運營模式都有所不同，需要不同的適配工作，從而摸索出最適合本企業的最佳實踐，照搬可能存在無法推進的問題，但SCF框架模型卻存在可取性，不同企業也能根據這樣的框架進行自問自答，不停調整和最佳化，從而能更加高效地快速發現，快速響應，快速恢復。