黑客都是連環作案！Dridex和FriedEx開發者同屬一人！

Dridex一直是計算機用戶、公司和金融機構的噩夢。對於很多人來說，談及銀行木馬，首先想到的就是它。最近，ESET的研究表明，臭名昭著的Dridex銀行木馬的作者是另一個備受矚目的惡意軟體家族的幕後黑手。該軟體是由ESET檢測到的複雜的勒索軟體Win32 / Filecoder.FriedEx和Win64 / Filecoder.FriedEx，也被稱為BitPaymer。

Dridex

Dridex銀行木馬在2014年首次出現，最初是一個相對簡單的受老項目啟發的機器人，但作者很快將這個機器人變成了市場上最複雜的銀行木馬之一。該木馬發展穩定，每周會發布小修正和更新，偶爾休息一下。有時候，作者還會引入重要更新，增加一些關鍵的功能或大的變化。2017年初發布第3版到第4版的最後一次重大更新，因採用Atom Bombing注入技術而獲得關注，並在今年推出了新的MS Word 0day漏洞利用，該漏洞把木馬傳播給數百萬的受害者。

截至本文撰寫時，Dridex的最新版本是4.80，包括對Chrome版本63的webinjects支持。Dridex 4.80於2017年12月14日發布。

注意：去年我們發布了一個工具，可以幫助識別流行Web瀏覽器中的惡意鉤子。該工具旨在幫助事件響應者發現潛在的銀行木馬，包括Dridex。

FriedEx

依據勒索需求顯示的文本，此勒索軟體最初被稱為BitPaymer，Michael Gillespie在2017年7月初發現。八月份，它重新成為焦點，因感染蘇格蘭NHS醫院而登上頭條。

FriedEx專註於高規格的目標和公司，而不是常規終端用戶，通常通過RDP暴力攻擊傳播。勒索軟體使用隨機生成的RC4密鑰對每個文件進行加密，並保存為相應的.readme_txt文件，之後使用硬編碼的1024位RSA公鑰將RC4密鑰加密。

2017年12月，我們仔細查看了FriedEx的一個樣本，立即注意到代碼與Dridex有相似之處。深入分析FriedEx樣本，我們發現FriedEx與Dridex使用相同的技術以儘可能多地隱藏其行為。

它通過hash搜索來解決所有系統API調用，以加密形式存儲所有字元串，通過hash查找註冊表項和值等。由此產生的二進位文件在靜態特性方面非常低調，而且在沒有深入分析的情況下很難搞清楚惡意軟體在做什麼。我們開展了進一步的分析，揭示了一些額外的屬性，證實了我們最初的懷疑——這兩個惡意軟體家族由同一個開發者創建。

代碼相似性

圖1. Dridex和FriedEx樣本中的GetUserID函數比較

圖1中，我們可以看到生成用戶ID函數的一部分，該函數可在所有Dridex二進位文件（loader和bot模塊）中找到。正如我們所看到的，FriedEx二進位文件中也使用了與Dridex相同的函數。該函數生成相同的結果——它從受害者機器的若干屬性中生成一個字元串，作為受害者的唯一標識符，或在Dridex殭屍網路中，或在FriedEx勒索軟體中。值得一提的是，這些截圖會讓你有一種在玩「找差異」遊戲的感覺！

Dridex與FriedEx的這種相似性貫穿於整個二進位文件中，只有極少數與特定勒索軟體相對應的函數（即文件加密循環和創建贖金消息文件）未在Dridex樣本中找到。

圖2. Dridex和FriedEx樣本中函數順序的比較。另一個樣本中缺少的函數以相應的顏色突出顯示

另一個共享特徵就是二進位文件中函數的順序，當多個項目使用相同的代碼庫或靜態庫時，就會發生這種情況。如圖2所示，雖然FriedEx樣本似乎缺少Dridex樣本中的一些函數，反之亦然（編譯器忽略未引用/未使用的函數引起的），但順序保持不變。

注意：基於代碼地址（sub_CA5191和sub_2A56A2等）自動生成的函數名稱對明顯不匹配，但代碼卻是相同的。

還有一點，Dridex和FriedEx都使用相同的惡意軟體殼。然而，由於加殼如今非常流行（可能是因為其避免檢測和阻礙分析的有效性）並被其他知名的家族（如QBot，Emotet或Ursnif）使用，所以我們並不認為這是單獨的有力證據。

PDB paths

在構建Windows可執行文件時，鏈接器可能會包含指向調試符號文件的PDB（程序資料庫）路徑，這些符號可幫助開發人員調試和識別崩潰。實際的PDB文件不存在於惡意軟體中，因為它是一個單獨的文件，沒有分發。但是，有時僅僅路徑就（如果包含的話）可以提供有價值的信息，因為PDB文件與默認編譯的可執行文件位於同一目錄中，並且通常也具有相同的名稱，後跟.pdb擴展名。

正如人們所想，PDB路徑通常不包含在惡意軟體的二進位文件中，因為攻擊者不想泄露任何信息。幸運的是，這兩個家族的一些樣本確實包含了PDB路徑。

圖3. Dridex和FriedEx項目中找到的所有PDB路徑

如圖3所示，兩個項目的二進位文件都在相同的、獨特命名的目錄中。基於對所有惡意軟體樣本元數據的搜索，我們得出結論：S:Work_bin是Dridex和FriedEx項目獨有的。

時間戳

我們發現Dridex和FriedEx的幾個樣本編譯日期相同。這當然可能是巧合，但經過仔細觀察，我們很快就排除了「純屬巧合」的理論。我們不但發現在同一天的編譯最多僅有幾分鐘的時間差（這意味著Dridex的人可能同時編譯這兩個項目），而且隨機生成的常量在這些樣本中也是相同的。這些常量會隨著每次編譯的變化而變化，使分析更加困難，並避免檢測。這可能是因為每次編譯中隨機因素或許基於像當前日期的一些變數。

圖4. Dridex樣本中的GetAPIByHash函數，編譯時間差為3天，突出顯示的常量不同

圖4中，我們比較了兩個Dridex loader樣本編譯時間差三天。雖然loader幾乎完全相同，唯一區別的是它們的硬編碼數據（如加密密鑰和C＆C IP），但常量也不同，所有基於它們的hash也不同。 另一方面，圖5中，我們可以看到同一天FriedEx和Dridex loader的比較（事實上，時間僅相隔兩分鐘）。此處，常量是相同的，這意味著二者可能在同一編譯會話中建立。

圖 5.Dridex和FriedEx二進位文件中的GetAPIByHash函數在同一天編譯，突出顯示的常數在兩個樣本中相同

編譯信息

編譯器信息進一步支持我們發現的所有證據——Dridex和FriedEx的二進位文件都在Visual Studio 2015中編譯。這可通過在PE Header和Rich Header數據中找到的鏈接器版本來確認。

圖6. Dridex 和 FriedEx樣本中發現的Rich header數據

除了與Dridex明顯的相似之外，我們遇到了一個之前未被報道的勒索軟體的64位變種。由於通常的32位版本的勒索軟體可以同時針對x86和x64系統，我們認為這個變種有點意思。

結論

有了這些證據，我們確認FriedEx系是Dridex作者所為。這一發現讓我們更好地了解了該組織的活動情況——我們可以看到，該組織繼續保持活躍，不斷更新其銀行木馬，以保持對最新版本Chrome的webinject支持，並引入新的功能，如Atom Bombing，但它也遵循最新的惡意軟體「趨勢」，製造自己的勒索軟體。

我們只能猜測未來會發生什麼，但可以肯定的是，Dridex團伙不會很快消失，他們將不斷創新舊項目，並可能衍生出新的作品。

很長一段時間，人們相信Dridex團伙只是「一招鮮」，他們把注意力集中在銀行木馬上。現在我們發現情況並非如此，他們適應最新的趨勢，創造出一種可以與同類競爭的不同類型的最先進惡意軟體。

IoCs

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！