目前假設情境是攻擊者已經入侵,並開始執行 powershell
這裡假設攻擊者想先關閉受害者機器上的保護機制,如
這裡探討調查 防禦被關閉 的相關紀錄
如果 Windows Defender 正常運作,
攻擊者後續使用的工具、腳本或 Payload 都可能被偵測。
因此,常見的 Defense Evasion 行為之一,就是修改 Defender 設定。
概念上可以分成幾類:


Defender 也有自己的 Operational Log。
調查時可以查看:
Microsoft-Windows-Windows Defender/Operational
其中一些事件可用來了解:
例如 Event ID 5007 常與設定變更有關。
而這些紀錄,有價值的地方是要把時間線串起來:
Defender 設定變更
↓
誰做的?
↓
前後有什麼 Process?
↓
同時間是否建立新檔案?
↓
之後是否出現外連?
攻擊者不一定非得把 Defender 整個停掉。
有時候只要讓某一條偵測路徑失效就夠了。
其中一個重要目標就是: AMSI(Antimalware Scan Interface)
它提供一個介面,讓應用程式把 Script 或動態內容交給防毒引擎檢查。
例如:
PowerShell
│
▼
AMSI
│
▼
Antimalware Engine
因此,即使攻擊者的 PowerShell 沒有寫成檔案,
部分 Script 內容仍可能有機會被掃描。
如果攻擊者能讓 AMSI 失效,
就可能降低某些 Script 執行內容被資安產品檢查的機會。
常見研究會討論:
但從藍隊角度來說,該注意的是:
PowerShell 或其他 Script 附近,有沒有出現異常記憶體操作、可疑程式碼載入等。
這類訊號通常更適合底下種類做觀察:
PowerShell 還有一個常被誤解的東西是 Execution Policy。
例如:
它可以降低使用者「不小心執行腳本」的機率。
但它不是設計來對抗具備程式碼執行能力的攻擊者。
所以 Microsoft 本身也把它視為:Safety Feature
而不是 Security Boundary。
可以把它想成:
Execution Policy ≈「提醒與限制」
而不是:
Execution Policy =「攻擊者無法執行 PowerShell」
所以看到底下是值得注意:
-ExecutionPolicy Bypass
但上述不要誤以為「Execution Policy 被突破了,所以主機才淪陷」。
通常攻擊者已經取得某種程式碼執行能力,才會用到這類參數。
重點澄清:PowerShell 的執行原則不是安全功能,只是防止使用者誤跑腳本的防呆設計,微軟自己也這麼說:https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-7.6

攻擊者下一個問題是:我需要更多功能。
例如:
但自己寫一支工具:
那乾脆用現成工具。
這類模式常被稱為:
BYOT — Bring Your Own Tools
BYOT 不等於「工具是惡意的」
例如一些合法工具:
都有完全正常的用途。
問題是攻擊者也能用。
例如:
PsExec
→ 遠端執行
AnyDesk
→ 遠端控制
rclone
→ 大量資料傳輸
7-Zip
→ 壓縮準備外洩
所以藍隊看到這些工具時,需要思考:
「這台機器正常會用它嗎?」
實務工作,會很常需要跟對方客戶確認這類工具的存在是否合理

攻擊者也常把工具丟到一些臨時檔案分享站(如 temp.sh 這類服務)再下載進來,避免直接夾帶。
這帶出一個 Day 26 會討論的想法:如果工具都是合法的,只能靠「這程式出現在這裡、這個時間、做這件事,合不合理」。
「關閉防禦」在正常維運中極少發生,所以它是訊噪比極高的偵測點。

當一台機器的防毒「突然安靜下來」或「突然多了排除項目」,是攻擊正在進行的訊號。
明天會拿一段真實攻擊常見的「編碼+混淆 PowerShell」,一步步用工具把它剝開,還原出攻擊者真正想做的事。