當我們的客戶受到AT&T Alien Labs識別出來新的資安威脅攻擊時，我們的SOC分析人員能阻止攻擊繼續的發展和延伸。請了解最新blog中關於SOC-RIG的漏洞攻擊包事件處理…

摘要

這個blog描述了由AT&T SOC分析人員團隊針對AT&T託管威脅檢測和事件處理, 撰寫的最新安全事件調查和分析報告。

AT&T AlienLabs®Open ThreatExchange®（OTX）最近建立了一個新的Pulse名為RIG Exploit Kit(RIG的漏洞攻擊包)，據觀察該漏洞是向各個行業的受害者公司分發勒索軟體的。BroadAnalysis發現了此漏洞，BroadAnalysis在 2019年12月2日發布的白皮書中概述了該漏洞的複雜性。BroadAnalysis提供了此漏洞的生命週期的分步說明，包括所有入侵指標（IOC）。利用OTX中產生的Pulse和Alien Labs的威脅情資，AT&T的安全運營中心（SOC）能夠識別此威脅的最初行為，並與客戶和員工協同合作以減輕正在進行的攻擊活動。

調查

初步警報審查

入侵指標（IOC）

最初的警報是由於對OTX IOC usa.lucretius-ada[.]com（與MITRE ATT&CK的第一階段相關聯的IOC）提出的域名系統（DNS）request而浮出水面的。

經過進一步審查，我們意識到此警報是根據DNS的request而觸發的。經過初步分析，我們確定流量與終端上發生的感染沒有直接關係，因此我們有意識地決定擴大調查範圍。

擴大調查

事件搜索

鑑於我們作為IOC在該域上獲得了積極的成功，因此我們對與該域匹配的所有事件進行了查詢。隨後，我們發現了十二個防火牆事件，這些事件從不同的起源點傳到該域，而不是警報中找到的最初來源。匯總相關事件後，我們確定有六個唯一的來源已建立與此域的連接。

查看這些源設備後，根據其主機名，似乎有兩個是手機，而其他設備似乎是用戶端點或可能是伺服器。這些資產不是USM Anywhere中的註冊資產；因此，我們無法獲得其他信息。鑑於對未註冊資產的了解有限，在這一點上，我們不得不依靠與客戶進行交互，以驗證這些設備是否易受攻擊，以及如何計劃我們的途徑來阻止這種威脅。

事件深度分析

現在，我們已經觀察到成功的網路流量到了惡意域，我們回到了Broad Analysis的白皮書。我們匹配的指標是該域上的特定URL。查看白皮書，指標是：

usa.lucretius-ada.com GET / zcvisitor /

我們從這六個來源的每個防火牆日誌中都觀察到了該URL。目前，我們可以放心地說，有六台設備已成功連接到惡意URL，並且很可能已感染了該RIG 的漏洞攻擊包。

審查其他指標

發現這些受感染的端點之後，我們開始為調查構建註釋。同時，我們查看了BroadAnalysis白皮書，以查找由這些設備執行的網際狙殺鍊的其他步驟。值得慶幸的是，我們

沒有發現任何其他指標，而且看來我們仍處於漏洞利用的第一階段。

回應

建立調查

鑑於情況的緊急性，我們為客戶建立了高嚴重性調查。利用USM Anywhere的功能，我們生成了CSV報告，其中包含我們能夠觀察到的全部事件活動，因此他們可以了解事件和情況。

附上我們的報告後，我們向客戶提供了記錄，其中包括對我們觀察到的內容的分析，建議的操作以及指標的參考。

客戶互動

客戶的最初反饋是他們在防火牆中阻止了該域，以防止將來嘗試連結。此外，他們打開了內部的support ticket，以對受影響的電腦進行驗證並re-imaged。

限制與機會

限制

• 在此調查期間，我們只能訪問防火牆和DNS日誌。因此，我們的取證功能有限，並且嚴重依賴客戶互動來確認似乎的惡意活動。

機會

• 與客戶合作部署其他AlienVault代理程式，將使我們能夠從正在調查的資產中收集更多遙測信息，並更快地對威脅進行分類。

感謝iThome的報導😃😃😃

https://www.ithome.com.tw/pr/136500

Bleeping Computer報導了新的Megacortex勒索軟體更改Windows密碼，威脅要發佈數據…

發現了新版本的MegaCortex勒索軟體，不僅可以加密您的文件，而且現在可以更改已登錄用戶的密碼，並威脅說如果受害者不支付贖金就可以發佈受害者的文件。

對於不熟悉MegaCortex的用戶，它是通過木馬（例如Emotet）提供的網

路訪問安裝的定向勒索軟體。一旦MegaCortex參與者獲得了訪問權，他們就可以通過活動目錄控制器或後利用套件將勒索軟體推送到網路上的電腦。

MegaCortex新版本中的重大更改

在由MalwareHunterTeam發現，由Vitali Kremez反向工程，並由BleepingComputer進一步分析的勒索軟體的新樣本中，我們看到了MegaCortex的新版本，該版本與以前的變體相比有很大的變化。

受害者看到的最明顯的變化是勒索軟體正在使用新的.m3g4c0rtx 的擴展名，如下所示。

此外，MegaCortex將在加密的電腦上配置的法律聲明，以便在用戶登錄之前顯示帶有電子郵件聯繫人的基本“已被MegaCortex鎖定”勒索消息。

當執行主MegaCortex啟動器時，它將啟動兩個DLL文件和三個CMD腳本到C：\ Windows \ Temp。目前，此發射器已通過Sectigo證書籤署給名為“ MURSA PTY LTD”的澳洲公司。

這些CMD文件將執行各種命令，以刪除卷影副本，使用Cipher命令擦除C：\驅動器上的所有可用空間，設置法律聲明，然後清除所有用於加密電腦的文件。

Kremez在對話中告訴BleepingComputer，這兩個DLL文件用於加密電腦上的文件。一個DLL文件是一個文件迭代器，它查找要加密的文件，而另一個DLL將用於加密文件。

這些DLL不會注入到任何進程中，而是通過Rundll32.exe運作。

完成後，受害者將在桌面上找到贖金記錄，標題為！–！_ README _！-!. rtf

經過進一步分析，我們確定至少有一種威脅是真實的。勒索軟體確實更改了受害者Windows帳戶的密碼。

MegaCortex更改受害者的Windows密碼

對於勒索軟體開發人員來說，為了嚇受害者支付錢財而製造沒有進行的威脅並不少見。

因此，當我們看到贖金通知書指出受害者的憑證已被更改時，我們將其駁回。

“您的所有用戶憑據已更改，並且您的文件已加密。”

測試勒索軟體並重新啟動加密的電腦後，我發現無法登錄我的帳戶。

Kremez對代碼進行的進一步分析證實，MegaCortex確實在更改受害者Windows帳戶的密碼。

它通過在執行勒索軟體時執行net user命令來實現。

這也解釋了為什麼攻擊者添加了一條法律提示，該提示在登錄提示處顯示，因為用戶將不再能夠登錄以存取他們的桌面。

威脅要發佈受害者的數據

除了已證實的更改用戶憑據的聲明外，攻擊者還更改了贖金記錄以聲明受害者的數據已複製到安全位置。

然後，他們威脅說，如果受害者不支付贖金，則必須公開此數據。

“我們還將您的數據下載到了安全的位置。不幸的是，如果我們未達成協議，我們別無選擇，只能將這些數據公開。

交易完成後，我們已下載的所有數據副本將被刪除。”

尚不確定攻擊者是否確實複製了受害者的文件，但是不應

打發這種威脅，受害者可能希望確認攻擊者與他們進行通訊時確實擁有他們所說的文件。

但是，如果MegaCortex參與者實際上在複製數據，受害者現在將不得不將這些攻擊視為未來的數據洩露，而不僅僅是勒索軟體感染。

這最終將為這些類型的攻擊增加一層全新的複雜性和風險。

更新11/7/19： Sectigo告訴BleepingComputer，他們已於美國東部時間11月5日下午4:20吊銷了該惡意軟體使用的證書。

Hashes：

ca0d1e770ca8b36f6945a707be7ff1588c3df2fd47031aa471792a1480b8dd53 [Launcher]

5ff14746232a1d17e44c7d095e2ec15ede4bd01f35ae72cc36c2596274327af9 [DLL]

e362d6217aff55572dc79158fae0ac729f52c1fc5356af4612890b9bd84fbcde [DLL]

關聯文件：

!-!_README_!-!.rtf

贖金文字：

新的Web緩存系統中毒攻擊, 使用CDN(內容傳遞網路)的站點…

有關新的Web緩存中毒攻擊的詳細信息已經出現，這些攻擊可用於拒絕用戶訪問通過內容傳遞網路（CDN）分發的資源。

該新方法名為“緩存中毒拒絕服務（CPDoS）”，它具有多種變體，可以通過發送帶有格式錯誤的標頭的HTTP請求來工作。

通過緩存服務器進行DoS

CDN具有通過緩存客戶端經常請求的資源來減少使用其服務的原始伺服器上的通信量的特性。這樣做的直接效果是提高了性能。

CDN體系結構中的緩存系統通常分散在較大的地理區域中，以實現更好的分發，它存儲源伺服器中資源的最新版本，並在客戶端請求時將其交付給客戶端。

這些中間系統處理請求並將其轉發到目的地，等待回應和資源的新版本（如果存在）。使用標識新變體的緩存鍵可以確定資源的新鮮度。

CPDoS在CDN的中間緩存系統級別工作，該緩存系統接收並存儲由錯誤的HTTP請求標頭引起的錯誤頁面。

結果，嘗試訪問相同資源的用戶將收到緩存的錯誤頁面，因為這是原始伺服器在請求後返回的帶有錯誤標頭的內容。

攻擊的變化

Cologne大學應用科學和德國漢堡大學的Hoai Viet Nguyen，Luigi Lo Iacono和Hannes Federrath描述了CPDoS攻擊的三種變化：

HTTP標頭超大Header Oversize（HHO）

HTTP元字符Meta Character（HMC）

HTTP方法覆蓋Method Override（HMO）

使用HHO類型的CPDoS攻擊，威脅參與者會利用為HTTP請求標頭設置的大小限制中間系統和Web伺服器。

如果緩存系統接受的請求標頭大小大於原始伺服器定義的請求標頭大小，則攻擊者可以使用超大請求密鑰或多個標頭來製作請求。

在這種情況下，緩存將轉發帶有多個標頭的請求，並且網

路伺服器將阻止該請求，並返回一個400 Bad Request錯誤頁面，該頁面將被緩存。以後對相同資源的請求將獲得錯誤頁面。

為了更好地說明這種情況，研究人員製作了一個視頻，目標是託管在Amazon CloudFront上的應用程式。

在攻擊過程中，錯誤頁面將有選擇地替換資源，直到整個網頁都不可用為止。

HTTP元字符（HMC），CPDoS攻擊的第二種變體與HHO類似，但利用了有害的元字符。這些是任何“控製字符，例如中斷/回車符（‘\ n）‘，換行符（‘\ r’）或鈴聲（‘\ a’）”。

再次，高速緩存系統執行其工作並轉發從客戶端收到的請求。當它到達源伺服器時，它可能被分類為惡意程式，並生成一條錯誤消息，該消息被緩存並呈現給客戶端而不是所請求的資源。

該方法超越了攻擊（HMO），這是CPDoS的第三種變體，它從僅支持GET和POST HTTP請求方法的中間系統（例如代理，負載平衡器，緩存，防火牆）中獲利。

這轉化為阻止其他HTTP請求方法。一個提供Web應用程式指示信息以替換標頭中支持的HTTP方法的Web框架允許繞過安全策略並提供不同的安全策略，例如DELETE。

在上圖中，GET請求被覆蓋，原始伺服器上的Web應用將其解釋為POST，並返回相應的回應。

“讓我們假設目標Web應用程式未對/index.html上的POST實現任何業務邏輯。在這種情況下，諸如Play Framework 1之類的Web框架會 返回一條錯誤消息，狀態碼為404 Not Found。”

結果是該錯誤消息被緩存並用於/index.html資源的後續有效GET請求。

下面的視頻演示了CPDoS攻擊的這種變體，它使用Postman  工具測試Web服務來阻止對目標網站主頁的訪問。

影響深遠

CDN在較大的地理位置上運行，CPDoS攻擊生成的錯誤頁面可以到達多個緩存伺服器位置。

但是，研究人員發現，並非所有邊緣伺服器都受到此威脅的影響，並且某些客戶端仍將從原始服務器接收有效頁面。

在測試中，他們使用了TurboBytes Pulse（全局DNS，HTTP和traceroute測試工具）和網站速度測量服務。

針對同一國家德國（法蘭克福）和（科隆）的目標發起的攻擊影響了整個歐洲和亞洲某些地區的緩存伺服器。

解決問題

這種DoS攻擊的標頭超大（HHO）和元字符（HHM）變體是可能的，因為它與標準HTTP實現有所不同，默認情況下，標準HTTP實現不允許存儲包含錯誤代碼的回應。

“ Web緩存標準只允許緩存錯誤代碼‘404 Not Found’，‘405 Method Not Allowed’，‘410 Gone’和‘501 Not Implemented’，”研究人員在CPDoS的網站上寫道。

阻止DoS受到這些攻擊的最簡單方法是遵守HTTP標準並僅緩存上面定義的錯誤頁面。

但是，由於內容提供者使用更通用的狀態代碼，因此使用不適當的狀態代碼來處理錯誤也會啟用這些攻擊。例如，“ 400錯誤請求”用於聲明過大的標頭。正確的是“ 431請求標頭字段太大”，研究人員分析的任何系統都沒有緩存它。

針對HHO和HHM CPDoS變體的全面解決方案是將錯誤頁面完全排除在緩存之外。

保護措施還包括在緩存前面設置Web應用程序防火牆（WAF），以捕獲試圖到達原始服務器的惡意內容。

存在於多個CDN上的問題

從三位學者進行的測試來看，亞馬遜的CloudFront CDN似乎最容易受到CPDoS威脅。

在研究人員測試的25個流量服務器和Web框架中，只有其中三個的HTTP實施不受CPDoS攻擊：Apache TS，Google Cloud Storage和Squid。

下表顯示了此類Web緩存系統和HTTP實施的組合受此類拒絕服務的影響。

已將問題報告給受影響的各方，其中一些人發布了補丁或以其他式糾正了它們。

Microsoft更新了IIS Server的修復程式，並於6月發布了有關漏洞的詳細信息（CVE-2019-0941）。Play Framework還在1.5.3和1.4.6版本中針對HMO方法修補了其產品。

但是，並非所有供應商的反應都相同。與Flask開發人員進行了多次聯繫，但沒有回复，並且對CPDoS的彈性尚不清楚。

Amazon的安全團隊承認CloudFront的弱點，並在default的情況下停止使用狀態碼“ 400 Bad Request”緩存錯誤頁面。但是，研究人員說，溝通主要是一種方式，因為他們從未收到有關緩解進度的最新信息。

Hoai Viet Nguyen，Luigi Lo Iacono和Hannes Federrath在《您的緩存已下降：緩存中毒的拒絕服務攻擊》一文中詳細介紹了這種Web緩存中毒攻擊及其變化。

他們將在11月14日於倫敦舉行的第26屆ACM Conference on Computer and Communications Security（CCS）會議上發表該論文。

更新[10/23/2019]：  CloudFlare回應BleepingComputer的評論請求說，它為影響其係統的CPDoS方法增加了緩解措施。

為了與HTTP方法覆蓋（HMO）對抗，該公司將特殊標頭添加到了存在這些標頭的緩存鍵中。“這確保了使用標頭發出的請求不會毒化沒有它們的請求的緩存內容。”

對於其他兩種方法（標頭超大（HHO）和元字符（HMC）），CloudFlare的系統不會緩存“ 400錯誤請求”頁面。

公司代表告訴BleepingComputer：“我們還沒有發現使用本文所述漏洞的大規模攻擊方法。”

Akamai今天發表了一篇文章，  說他們的緩存系統遵循標準的HTTP實施，並且不受CPDoS攻擊方法的影響。

但是，可以實現非標準配置，並允許緩存錯誤消息。該公司建議其客戶檢查設置的自定義是否會使他們的網站容易受到攻擊。

Source: http://spr.ly/60161yiAK

雲端安全和風險緩解

雲端確實提供了它的優勢，但與任何大規模部署一樣，雲端可以提供一些無法預料的挑戰。雲端只是“別人的數據中心”的概念一直是一個令人畏縮的想法，因為這想法是假設安全責任的轉移，因為“別人會照顧它”。

是的，雲端系統，網路和應用程式序並非實際位於您的控制範圍內，而是安全責任和緩解風險。雲端基礎架構提供商可以在您設置環境的方式，您在環境中放置的內容，如何保護數據以及如何監控環境方面實現大量控制。在整個環境中管理風險並與現有安全框架保持一致。

隱私和風險

隨著GDPR和其他州的“姐妹”政策例如在Arizona，Colorado, California和其他組織在保護雲端中的數據方面面臨著越來越高的要求。它並不像在數據中心部署資料外洩防護（DLP）那麼簡單，因為。您現在有一堆不再由你擁有的服務，系統和基礎架構，數據中心已變得不完整的, 但您仍需要可見性和控制權。

共享或交換信息的雲端服務和基礎架構也變得難以管理：誰有服務層級協議(SLA)？是否單一平台可以監控一切？DevOps使企業採用微分段和調整防火牆規則變更管理流程。此外，無伺服器計算通過允許開發人員運行代碼而無需擔心基礎架構和平台，為組織提供了降低成本和提高工作效率的方法。然而，如果沒有處理虛擬私有雲和工作量負載的部署，事情就會很快失控，您就會開始看到從一個環境洩漏的數據，就像您在另一個環境中獲得了一個安全級別一樣。

緩解

可以採取幾個步驟來幫助降低組織在雲端中的數據風險。

1. 設計對齊。首先，將您的雲端環境與網路安全框架保持一致。組織遷移到雲端，他們使應用安全控制於落地部署數據中心，這些數據中心隨著時間的推移而不斷發展和變強。此外，組織可以放寬廣泛使用SaaS應用程式上的安全顯微鏡。但即使使用這些合法的業務應用程式，如果沒有正確的可見性和控制權，數據最終可能會被洩露。雲端提供商技術與網路安全框架和業務運營程式保持一致，可以實現雲端平台的高度安全，優化和更高效的實施，從而提供更好的結果和成功的部署。

 2.請隨便一點，就像在自己家一樣。應該像對待LAN和數據中心一樣對待雲端系統網路。例如Amazon的共同責任模式，概述Amazon安全責任的終結，並開始履行您的安全責任。雖然存在計算層的威脅，正如我們在Meltdown，Foreshadow和Spectre中看到的那樣，最近的雲數據洩露已經顯示出組織安全責任區域的崩潰，即操作系統安全性，數據加密和訪問控制。如果您的組織具有管理服務器配置，漏洞管理，修補，IAM，加密，分段，防火牆規則，應用程式開發和監視的標準，請確保這些標準適用於雲端服務並定期進行審計。第三方對雲端基礎架構體系結構的常規評估可以像審核LAN和WAN一樣有效，以獲得最佳安全實踐。

3. 停止“晚上偷偷溜出去”。不久之前，您會發現組織正在努力與員工建立不安全的無線接入點，以便在日常工作中獲得更大的靈活性和效率。暱稱是“影子IT”，業務部門避免讓IT和安全性涉及他們正在做的事情，以便他們能夠更快地行動。快進到今天 – 提供惡意檢測和入侵防禦系統（IPS）功能的無線控制器幫助了這項活動。通過雲端，員工可以根據需要設置雲端存儲帳戶，無伺服器計算環境和虛擬專用網路，以避免冗長和繁瑣的變更控製程式，降低成本並獲得類似的靈活性和效率。通過重新架構傳統網路，重新調整數十年的流程和程式。

4. 密切關注。網路安全運營中心（CSOC）不再僅僅關注落地網路和數據中心。SOC使用的運營監控程式，威脅搜尋，情報和事件回應也適用於組織數據所在的雲端環境。監控公司數據可能駐留的SaaS應用程式具有挑戰性，但可以使用有效的端點安全性以及雲端訪問解決方案（CASB，代理和其他）的監控來完成。對於無伺服器環境，根據您的CSOC要求，這可能意味著應用第三方監控平台或解決方案超出雲端提供商提供的範圍。在所有情況下，事件記錄和觸發器都需要反饋到CSOC以與落地事件數據，分析和威脅情報相關聯。

隨著所有可用的雲端服務以及每天提供的新服務，難怪公司難以管理風險。  “盡一切努力完成工作”到“做正確的業務”的文化轉變需要大量的協調努力和時間，但根植於安全成為業務推動者而不是繼續在‘不‘的業務。如果安全性要繼續保護業務，組織必須在技術決策中包含安全性，並且安全性必須了解業務需求和技術變化才能成為推動者。為了幫助阻止人們尋求技術問題解決方案，IT和安全團隊必須發展他們的資產和功能，以適應這種速度和便利。  

Source: spr.ly/6015Efmal