跳過主内容

給事件回應者修復系統性身份危害的建議

Detection and Response Team (DART) 

隨著Microsoft與業內合作夥伴以及安全社群,一起繼續調查Solorigate的攻擊範圍,我們的目標是提供最新的威脅情報,包括IOC以及我們所有產品和解決方案的指南,以幫助整個社群應對威脅、加固基礎架構,並從這種前所未有的攻擊中恢復。隨著新資訊的發佈,我們將持續更新這篇文章

這篇部落格文章將概述在本機和雲端環境中,我們從Solorigate事件與其他事件的回應過程所獲取的經驗。這份最新指南適用於所有憑證遭受Solorigate惡意軟體破壞,並希望重建可信任身份的客戶。

本文旨在透過我們過去的類似經驗,為事件回應者提供技術建議,以幫助組織應對可疑的系統性身份威脅(如我們在Solorigate惡意軟體受害者中所見)。我們希望將影響業務程度降至最低,重建對組織內部和雲端環境的信任,這需要進行深入的調查並了解攻擊者潛在持續方法。儘管我們無法涵蓋所有情況,但我們將在本篇指南中分享類似的客戶經驗,若在後續事件中獲取新資訊,我們將持續更新文章。如果您需要額外的資訊,請查看文末的連結。本篇資訊內容為通用指南,客戶必須考慮組織的獨特環境與需求,依據自身條件決定如何將本內容應用於IT環境。

本指南中的Solorigate調查在文章發佈時仍持續進行中,我們的團隊將繼續於第一時間回應這些攻擊。一旦獲取最新資訊,我們將透過Microsoft安全回應中心(MSRC)部落格更新。

入侵過程概覽

如同這篇Microsoft部落格文章中所述,此惡意行為者的活動包括(但不限於以下)這些可能導致系統性身份危害的技術:

  • 透過SolarWinds Orion產品中的惡意程式碼入侵。這讓攻擊者能夠進入網路,並獲得更高的憑證。Microsoft Defender現在可以偵測到這些文件。請閱讀我們對Solorigate惡意軟體的深入技術分析
  • 入侵者(透過危害本機)使用管理權限,來獲得受組織信任的SAML token簽章認證。如此一來,他們可以偽造SAML token來冒充組織任何現有使用者和帳戶,包括權限較高的帳戶。
  • 使用偽造token簽章認證的SAML token的異常登入,可用於任何本機資源(無論是身份認證系統或供應商)以及任何雲端環境(無論供應商身份),因為系統已經設定信任認證。組織可能會因非法SAML token使用的合法認證簽章,而忽略掉這些漏洞。
  • 使用(透過上述技術或其他方式獲得的)較高權限帳戶,將非法憑證加入現有應用程式的服務主體中,讓攻擊者可以藉由該應用程式的權限使用API。

回應目標概覽

經歷過系統身份危害的組織,需要重新建立可信賴的通訊。這會讓業務運作復原能夠有效分類和協調。

許多組織具有復雜的內外部相互依賴性。在復原工作期間,組織中的核心業務流程和應用程式可能會暫時受到影響,直到您的環境重建信任為止。Microsoft建議事件回應者要與組織的主要人員建立安全通訊,這是組織復原的第一步。若您的調查顯示攻擊者在組織較低級別的基礎結構上,使用了身份危害以外的技術,例如硬體或韌體攻擊,您需要解決這些威脅來降低再次受到危害的風險。

回應目標的大致順序:

  1. 為人員建立安全的通訊,這是調查和回應工作的關鍵。
  2. 調查持續性和初始存取的環境,同時在復原工作期間持續監控。
  3. 重取與保留對環境的管控,並修復或阻止可能的持續性技術和初始存取漏洞。
  4. 透過建議啟用安全功能,以改善狀態

我們建議事件回應人員在採取行動前先了解本指南內容,因為回應目標的行動必須依序伺機而動,且大多取決於調查結果(和完整性)以及特定組織的業務限制。以下各段落將介紹我們建議您針對上述目標採取的事件回應技術。

確保您建立安全的通訊和生產力

確保攻擊者不會竊聽您的通訊內容,才能成功回應威脅。在您確保目前基礎設施的通訊隱私前,請使用完全隔離的身份與通訊資源來回應與討論,避免攻擊者能夠獲取調查資訊。在您確認攻擊者都被清除前,我們強烈建議您隔離所有事件的相關通訊,以確保您能夠採取補救措施。

  • 透過電話通話、未連接至公司基礎架構的會議bridge和點到點加密訊息解決方案來開始一對一與群組對話。
  • 許多客戶透過建立一個新的Office 365租戶,維持安全生產力和協作。這個租戶與組織的生產租戶完全隔離,並只提供需要的人員,和回應過程中相關的事件回應供應商、合作夥伴。
    • 確保您以最佳方式來保護此租戶,特別是預設管理帳戶和權利。新租戶的管理權限應受到限制,並且不得與外部應用程式或供應商建立信任關係。若您需要更多協助,或想了解更多加強Microsoft 365的資訊,可以在此查看指南

調查您的環境

一旦事件回應者和關鍵人員有了安全的協作場所,下一步就是調查可疑環境。成功的調查是在深入分析異常行為(包含了解攻擊者活動和持續性的程度),以及防止攻擊者的更多行動之間取得平衡。若要成功修復,回應人員需要盡可能全面了解攻擊者控制的初始進入方法,和持續性機制。若遺漏的任何持續性機制,都可能導致攻擊者將繼續存取資料,並再次造成威脅。

  • 調查和檢視雲端環境紀錄中可疑動作和攻擊者的IOC,包含:
    • Unified Audit Logs(UAL)
    • Azure Active Directory(Azure AD)紀錄
    • Active Directory紀錄
    • Exchange本機紀錄
    • VPN紀錄
    • 工程系統紀錄
    • 防毒與端點偵測紀錄
  • 從端點審核紀錄檢視本機中的更改動作,包含(但不限於)以下項目:
    • 群組成員變更
    • 新建立的使用者
    • Active Director中的角色指派
    • 其他典型的入侵訊號
  • 檢視環境中的管理許可權
    • 檢視雲端中的特權存取,並刪除不必要的許可權。實施特權身份管理(PIM);設定條件式存取原則,在強化期間限制系統管理存取權。
    • 檢視本機部署特權存取,並刪除不必要的許可權。減少内建群組成員、驗證Active Directory委派、強化Tier 0環境,並限制誰能獲取Tier 0資產存取權。
    • 檢視所有允許下述內容的企業應用程式,了解委派許可權和同意授予(範例指令碼説明):
      • 特權使用者和角色修改
      • 讀取或存取所有郵件匣
      • 代表它人寄送或轉寄電子郵件
      • 存取所有OneDrive或SharePoint網站內容
      • 新增能夠讀取/寫入Directory的服務主體
    • 檢視以下Office 365產品的存取與配置設定:
      • SharePoint Online Sharing
      • Teams
      • PowerApps
      • OneDrive for Business
    • 檢視使用者帳戶
      • 檢視並移除不需要的來賓使用者。
      • 使用Hawk或類似工具檢視電子郵件配置。
        • 委派
        • 郵件匣資料夾許可權
        • 行動裝置上註冊ActiveSync
        • 收件匣規則
        • Outlook網頁版選項
      • 驗證所有使用者的MFA和自助式密碼重設(SSPR)聯繫資訊是否正確。

您可能會發現上述一個或多個記錄來源,是組織目前未涵蓋在安全規劃中的。其中一些記錄(特別是雲端中可用的記錄)僅在配置時可用,因此我們建議您盡快進行配置,以啟用下一節中的偵測和紀錄認證檢視。若有法律、法規或保險目的,請確保您保留紀錄,來協助組織進行進一步的調查和證據留存。

建立持續性監控

您可以透過許多方式偵測到相關活動。組織偵測攻擊者行為的方式取決於您擁有的安全性工具,或您選擇用來部署的回應方式。

Microsoft已公開我們提供的一些核心安全產品和服務範例,並在發現與此攻擊者相關的新威脅情報時,持續更新這些文件。如果您使用其他供應商的產品,請查看供應商的建議;若您需要在您的環境中自行執行類似偵測,請查閱下方Microsoft文件,了解偵測技術。

若您在環境中使用Azure Sentinel,請查看SolarWinds Post-Compromise搜捕指南

若您使用Microsoft Defender for Endpoint,請查看此處的指南Microsoft Defender防毒指南

Azure Active Directory登入
您可以在Azure Active Directory登入畫面中查看此資訊,選擇適當的時間視窗,即可下載為CSV或JSON檔案。注意:您可以透過此介面下載互動式以及非互動式登入報告。取得結果後,您可以查看在「MFA結果」欄位中的「透過token聲明滿足的MFA要求」。

您也可以使用Get-AzureADAuditIgnLogs cmdlet(請參考此處的詳細資訊),並透過篩選,讓結果僅顯示與該欄位相符的返回入口,如本範例所示:

Get-AzureADAuditSignInLogs -All:$true -Filter “createdDateTime gt and createdDateTime lt ”  | where {$_.Status.AdditionalDetails -eq “MFA requirement satisfied by claim in the token”} | select-object CreatedDateTime, IpAddress,UserAgent, ResourceDisplayName, CorrelationId, RequestId, UserPrincipalName -ExpandProperty Status

如果您的ADFS環境設定發送滿足MFA的聲明,這可能不是很強的訊號。但對於許多使用ADFS的組織,這項聲明不包含在您的設定中;在這種情況下,聲明將是可能是攻擊者活動的強烈指標。您也可以增加額外的篩選器,或在程式碼的where句中添加條件,以提升您的信號比例,例如您可以只顯示來自聯合網域中的結果。

若偵測到可疑的登入記錄,您可以根據已識別的IP位置、使用者帳戶和/或其他指標(如UserAgent字串和使用者作業系統)進一步調查,如果你對自身環境足夠瞭瞭解,這些將是強而有力的指標。

風險登入事件分析

在某些情況下,Azure Active Directory及其身分防護平台將發佈攻擊者使用的SAML tokens相關風險事件。這些事件可以被標記為「unfamiliar properties」、「anonymous IP address」、「impossible travel」和其他這裡描述的風險事件。

您需要密切分析與系統管理特權帳戶相關的所有風險事件。同時,分析已解除或修復的事件也很重要,因為其中一些動作是自動完成的。例如,當使用者通過MFA驗證後,系統將自動修復匿名IP未至的風險活動。

偵測網域驗證

攻擊者可能會試圖操控記錄在Azure Active Directory Audit Log中,並反映在Unified Audit Log中的網域驗證策略。獲得了全域管理員特權的攻擊者,可以修改聯盟和/或受信任的網域。在Unified Audit Log、Azure AD Audit Logs和/或您的SIEM環境中,檢視與「設置網域驗證」相關的活動。確認所有活動都是已經預期與計劃的。

下方為從Unified Audit Log中返回入口,以及網域驗證設定操作相關指令範例。

Search-UnifiedAuditLog -StartDate -EndDate -ResultSize 5000 -Operations “Set domain authentication”

 

偵測與OAuth應用程式相關的服務主體憑證

如果攻擊者已獲得足夠認證控制權的特權,則攻擊模式包括找出能存取組織中任何使用者電子郵件的應用程式,並向該應用程式添加攻擊者控制的認證。在某些情況下,攻擊者修改這些應用程式並授予它們其他的許可權,例如存取組織中的所有電子郵件。

下述操作與攻擊者行為一致:

  • 新增服務主體憑證
  • 更新應用程式認證與秘密管理
  • 更新服務主體
  • 在服務主體中新增應用程式角色分配
  • 向使用者分配新增應用程式角色
  • 新增OAuth2PermissionGrant

偵測到透過應用程式存取電子郵件

使用Office 365的進階審核功能,您可以偵測到利用應用程式存取電子郵件的動作。您可以透過MailItemsAccessed功能,審核對Office 365內訊息的存取。

為Operation of MailItemsAccessed分析Unified Audit Log中的活動。

偵測服務主體的非互動式登入

登入報告中的Azure Active Directory提供服務主體發佈認證進行的非互動式登入的報告(如同攻擊中觀察到的)。分析服務主體報告的登入資訊,能獲取有價值的資料,例如:使用者用來入侵裝置並存取電子郵件的IP位置。

如果有證據顯示偵測到透過危害本機獲得的管理權限,存取組織全域管理員帳戶和/或受信任的SAML token簽章認證,Microsoft建議您立即採取以下措施:

修復和維持管理控制

重取和維持您環境的管控

若您在調查後發現,攻擊者在組織的雲端或本機環境中具有管理控制權,確保您能恢復控制權,且攻擊者無法持續取得控制權是非常重要的。您須採取的確切步驟,取決於您在調查中發現結果的持續性,包含調查完整性和發現攻擊者所有可能進入和持續留存組織的信心程度。儘管您可能有高度信心恢復控制權,但不完整的調查,仍會對業務運作產生極大的影響,因此在過去經驗中,大多組織都會選擇根據調查結果進行修復。

我們建議您在建立管理控制修復計畫時,考慮以下步驟,但確切的順序和時間須根據您的調查結果與攻擊者擁有的資產和持續性方法。

  • 確保您在這裡提到的操作,都是透過受信任的裝置進行的,這個裝置需要來自受信任的資源,例如特權工作站
  • 如果組織失去了對token簽章認證,或聯合信任的控制權,最好的方法是在修復本機時,移除信任和轉移到雲端身份。本份指南無法記錄詳細規劃,因為規劃需要仔細的計畫,並了解隔離身分後,對業務運作的影響。您可以查看Azure Active Directory指南與主要注意事項。
  • 如果您的組織選擇在恢復本機管理控制時,選擇不破壞信任,您需要在回覆本機管理控制和封鎖攻擊者再次存取簽章認證時,輪替您的SAML token簽章認證。您的組織必須遵循以下認證輪替指示,確保攻擊者無法繼續在您的網域中偽造token。

更換ADFS token簽章認證

對於受害或可能會受害的ADFS Token簽章認證,若僅輪替Token Signing認證一次,之前的認證仍會持續運行。這樣做是為了讓您在認證的到期日之前,能夠在正常簽章認證的轉換期間有寬限期來更新您的Relying Party Trusts。

注意:在ADFS環境中執行以下步驟,您將同時建立主要認證和次要認證,且在預設時段(五天)後,次要認證將提升為主要認證。若您有Relying Party Trust,這可能會在初始ADFS環境更改五天後造成影響,您需要在流程中考慮這點。您可以透過-Urgent,第三次取代主要認證,並移除次要認證或關閉自動認證輪替來解決這個問題。

如果您的組織認為需要用已知未受汙染的系統替換ADFS伺服器,而不是Token Signing Certificat,則可以按照以下步驟從您的環境中刪除現有的ADFS,並構建一個新的ADFS服務器。

刪除Azure AD Cloud Provisioning代理配置

若您的組織決定更換目前ADFS伺服器的認證,請依照下述指令,由ADFS伺服器開始:

1.檢查並確認您的AutoCertificateRollover設置為True

Get-AdfsProperties | FL AutoCert*, Certificate*

  • 若它並非True,您可以使用下述指令設定:

Set-ADFSProperties -AutoCertificateRollover $true

2.連接至Microsoft Online Service

Connect-MsolService

3.紀錄您的本機與雲端Token 憑證指紋與到期日。

Get-MsolFederationProperty -DomainName

4.使用Urgent讓ADFS不須將主要Token Signing認證轉為次要認證,即可替代它。

Update-AdfsCertificate -CertificateType Token-Signing -Urgent

5.在與Azure雲端同步前,請勿使用-Urgent允許兩個本機Token Signing認證,來建立次要Token Signing認證

Update-AdfsCertificate -CertificateType Token-Signing

6.透過本機的主要和次要認證更新雲端環境,並立即移除雲端token簽章的認證。若您未使用此方法完成步驟,將可能遺留舊版token簽章的認證來驗證使用者。

Update-MsolFederatedDomain -DomainName

7.確認您已經完成上述步驟,並移除步驟3出現的認證。

Get-MsolFederationProperty -DomainName

8.透過PowerShell撤回Refresh Token,您可以在這裡找到資訊,也可以了解如何在Azure Access Directory中撤銷使用使用者權限

  • 注意:這會讓使用者登出手機、目前正在使用中的信箱、以及所有使用tokenRefresh token的項目。

需要完成的雲端修復動作

  • 重設緊急存取帳戶的密碼,並減少使用它們的次數
  • 我們建議擁有特權存取的服務與使用者帳戶,應限定為僅供雲端帳戶,且勿使用本機帳戶同步或連線到Azure Active Directory。
  • 強制租用戶中權限升級的使用者採用多重因素驗證(MFA)。我們建議您強制租戶中的使用者皆採用MFA。
  • 利用Privileged Identity Management (PIM)與條件式存取來限制管理權限。
    • Office 365使用者,可以利用特權管理(PAM)來限制對敏感性功能(包含eDiscovery、全域管理員、帳戶管理和其他)
    • 修改特權使用者與角色
    • 讀取、寄信或存取所有郵件匣
    • 存取OneDrive、Teams或SharePoint內容
    • 加入能夠讀取或寫入目錄(Directory)的Service Principals
    • Application Permissions versus Delegated Access

需要完成的本機修復動作

  • 重建在調查中被辨識為受感染的系統。
  • 從Domain Admins、Backup Operators和Enterprise Admin群組中移除不必要的成員。請參考Microsoft的保護特權帳戶
  • 為您環境中的所有特權帳戶重設密碼。
    • 特權帳戶並不限於內建群組,也包含指派至Server Administration / Workstation Administration和您環境中其他地方的群組。
  • 使用這個程式碼兩次來重設krbtgt帳戶。
    • 注意:如果您正在使用僅供檢視的網域控制器,您需要運行檢視-撰寫網域控制器和僅供檢視網域控制器的程式碼。
  • 在您確認系統中沒有攻擊者的persistence mechanisms後,請排定重新啟動時間。這能夠幫助您移除常駐型惡意軟體。
  • 重置每個網域控制器的DSRM(Directory Services Restore Mode)密碼,讓它們更加特殊與複雜

修復或封鎖您在調查中發現的持續性攻擊

修復或封鎖您在調查早期發現的持續性攻擊技術。調查是需要反覆進行的過程,您需要在組織發現異常時進行補救的需求,以及攻擊者察覺偵測結果後改變技術和維持持續性的反應之間找到平衡。對Office 365帳戶而言,將自動修復已知的持續性技術,若您偵測到任何persistance technique,請使用描述中的程式碼。

修復使用者與服務帳戶權限

我們已經在上面介紹了使用者相關的建議動作,特別是在確保MFA的啟用,以及運行特定的修復程式碼,以清除已知的持續性技術。您可以考慮採取以下步驟來修復和還原使用者帳戶:

  • 根據受信任的裝置強制使用條件式存取
    • 若情況允許,請強制使用適合您組織需求的位置條件式存取。
  • 對於任何受懷疑遭入侵的使用者帳戶,請在清除後立即重新設定密碼,確保您保有中期計畫來重置目錄中的憑證。
  • 在更換憑證後,使用PowerShell來立即撤銷並更新token。您可以在這裡找到更多資訊,若需要其他資源,請點選在Azure Active Directory中緊急撤除使用者權限|Microsoft Docs

提升安全性的處理方式

發生安全性事件後,是組織反思安全策略和優先順序的絕佳時機。事件回應者通常會被要求提供組織面對新威脅時,應優先考慮哪些投資的建議。除了過去的資料,我們也建議您將事件發生後的建議內容,針對攻擊者使用的技術,以及攻擊和防護之間的安全性差距作為重點考量。

 

整體安全性

  • 若需了解為Microsoft產品與您使用的服務量身打造的安全性基礎建議,請查看Microsoft Secure Score
  • 確保您的組織擁有EDR與SIEM解決方案
  • 查看Microsoft的企業存取模型

身份

  1. 查看保護身份基礎架構的五個步驟,並為您的身份架構排定合適的優先順序。
  2. 考慮為您的驗證政策轉移至Azure AD Security Defaults-您可以在此查看細節
  3. 減少您組織內舊版驗證的使用量,若系統或應用程式仍需要使用舊版驗證-請查看這份指南
    • 就如我們去年所公布,Exchange Team計畫在2021下半年中,使EAS、EWS、POP、IMAP和RPS協定的Basic Authentication無效化。Security Defaults與Authentication Policies是分開的,但它們提供了全面功能。我們建議客戶使用Authentication Policies取代Basic Authentication,替換為Exchange Online協議中的subset,並為組織逐漸關閉Basic Authentication。我們將持續發布細節,就像我們在四月提到,我們計劃開始將截至2020年十月無使用紀錄租戶的Basic Authentication無效化。在無效化任何租用戶前,我們將透過Message Center的貼文通知您。
  1. 為了幫助您保護您的ADFS/Azure AD Connect系統,除了ADFS指南外,我們也建議您考慮下方式:
    • 將您的ADFS基礎架構與AD Connect基礎架構視為Tier 0資產。
    • 限制系統的本機管理存取權,包含用來運作ADFS服務的帳戶。
    • 透過Remote Desktop的Windows Firewall政策,將管理存取權限制在特定使用者與IP位置中。
      • 建議設置Tier 0 jump box或相似系統
    • 防止SMB從任何環境中存取系統。若需更多細節,請參考這個網站
      • 在SIEM中使用Windows Firewall logs以保留歷史紀錄與主動執行監控。
    • 若您目前已在使用Service Account,您可以在環境支援的情況下,轉移至group Managed Service Account (gMSA)。若您無法轉移至Gmsa,請將您Service Account的密碼設定得更複雜。
    • 您可以使用以下指令,確保ADFS系統中的Verbose logging已經啟用。

Set-AdfsProperties -AuditLevel verbose

Restart-Service -Name adfssrv

Auditpol.exe /set /subcategory:”Application Generated” /failure:enable /success:enable

Contributors: We thank the team at FireEye for their contributions and review.

致謝:感謝FireEye的貢獻與審核

若欲瞭解原文,請至微軟官方部落格參考。

延伸資料: