擁有相同的起源的Android惡意軟體家族——GM BOT&SlemBunk

weixin_34239169發表於2018-03-08
Android

Fnut · 2016/03/18 10:38

0x00 前言

二月19號，IBM XForce的研究員釋出了一個情報報告，這份報告聲稱GM BOT的原始碼在2015年12月被洩漏到了一個惡意軟體的論壇上。GM BOT是一個複雜的安卓惡意軟體家族，它出現在2014年末俄語地區的網路犯罪地下組織。IBM同時聲稱幾個在最近的安全會議上提出的Android惡意軟體家族實際上也是GM BOT的變種，包括Banskosy，MazarBot，以及FireEye最近提到的惡意軟體Slembunk。

安全廠商可能在一個惡意軟體的“變種”定義上各不相同。這一術語可以指完全相同的程式碼僅僅做輕微的改動，也可以指表面相似然而其他地方非常不同的程式碼（比如有相似的網路通訊）。

通過使用IBM的報告，我們分析了它們的GM BOT樣本和SlemBunk的樣本。基於這兩個家族的反彙編程式碼，我們認為有足夠多的程式碼相似性可以表明GM BOT和SlemBunk擁有相同的起源。有意思的是，我們的研究讓我們也認為早期的一個惡意軟體家族SimpleLocker（Android上最早為人所知的檔案加密型勒索軟體）也同樣具有和之前兩個家族相同的起源。

0x01 GM BOT和SlemBunk

我們的分析發現最近被IBM研究者提到的四個GM BOT樣本都和SlemBunk擁有相同的主要元件。如下圖所示，我們早期的報告展示了SlemBunk主要的元件以及相應的類名：

  • ServiceStarter：一旦一個應用被啟動或者裝置啟動就會呼叫這個Android接收器。它的功能是在後臺啟動監控服務，MainService。
  • MainService：執行在後臺並監控所有在裝置上執行的程式的Android服務。當一個應用被啟動後，它會為使用者提供一個覆蓋式的類似於合法應用的檢視。這項監控服務會通過傳送原始裝置資訊、告知裝置狀態和應用程式偏好來和一臺遠端主機進行通訊。
  • MessageReceiver：處理進入的文字資訊的Android接收器。除了攔截來自銀行的驗證碼的功能之外，這個元件也充當著作為一個傳送遠端命令和進行控制的機器人客戶端（C2）。
  • MyDeviceAdminReceiver： 當這個應用首次被啟動之後，這個接收器就會請求這個Android裝置的管理員許可權。這會讓這個應用更難被移除。
  • Customized UI views：呈現虛假登陸頁面的Android類，這些虛假的登入頁面都是模模擬正的銀行應用 或者社交應用的，這樣就可以進行釣魚來獲得銀行或者社交賬戶憑證。

前三個GM BOT樣本都和我們的SlemBunk樣本有相同的包名。除此之外，這些GM BOT樣本有5個相同的主要的元件，包括和上圖的SlemBunk樣本一樣，擁有相同的元件名稱。

第四個GM BOT有不同的初始化包名，但是會在執行時解壓真正的payload。解壓的payload擁有和SlemBunk相同的主要元件，只是在類名上有一些小的改變：比如MessageReceiver替換成了buziabuzia，以及MyDeviceAdminReceiver替換成了MDRA。

上圖展示的是GM BOT樣本（SHA256 9425fca578661392f3b12e1f1d83b8307bfb94340ae797c2f121d365852a775e）和一個SlemBunk樣本（SHA256 e072a7a8d8e5a562342121408493937ecdedf6f357b1687e6da257f40d0c6b27）之間程式碼結構的相似性。從這張圖中我們可以發現，我們之前討論的5個主要的元件也出現在了GM BOT樣本里。其他共同的類包括：

  • Main: 兩個例子中的啟動的activity。
  • MyApplication：兩個例子中在任何其他的activity啟動之前啟動的應用的類。
  • SDCardServiceStater:另外一個監視著MainService的接收器，一旦MainService掛掉了就把它重啟。

在上面所有的這些元件和類中，MainService是最重要的一個。它是在啟動時被Main類啟動的，並持續在後臺執行來監控執行最多的程式，當一個受害者的應用（比如一些手機銀行APP）被監控到時就將一個釣魚頁面覆蓋上去。為了保持MainService持續執行，惡意軟體作者新增了兩個receiver——ServiceStater和SDCardServiceStater，以此來檢查接收到特殊的系統事件時的執行狀態。GM BOT和SlemBunk樣本都有同樣的結構。下圖展示的SDCardServiceStater類的主要程式碼是為了說明GM BOT和SlemBunk使用了同樣的機制來維持MainService執行。

從這張圖中我們可以發現，GM BOT和SlemBunk使用幾乎相同的程式碼來保持MainService執行。值得注意的是兩個樣本都在系統區域設定中檢查了城市，如果是俄羅斯就不啟動MainService。唯一的區別就是GM BOT對某些類名、方法和欄位進行了重新命名混淆。比如，GM BOT中的靜態變數“MainService;->a”和SlemBunk中的“MainService;->isRunning”是同樣的功能。惡意軟體作者使用這種方式來讓他的程式碼更難去理解。然而這並不會改變根本的程式碼是來自於相同的起源這一事實。

下圖展示的MainService類的核心程式碼說明GM BOT和SlemBunk擁有相同的主服務邏輯。在Android中，當一個服務被啟動，就會呼叫它的onCreate方法。在兩個樣本中的onCreate方法裡，一個靜態的變數都會首先被設定為“True”。在GM BOT中，這個變數被命名為“a”，而在SlemBunk中它被命名為“isRunning”。並且它們都會去讀取應用程式偏好，並且在兩個樣本中有同樣的命名：“AppPrefs”。這兩個主服務的最後的任務也是相同的。如果一個受害者的應用在執行，一個釣魚的頁面就會覆蓋到受害者的應用之上。

0x02 SimpleLocker和SlemBunk

IBM聲稱GM BOT出現在2014年末俄語地區的網路犯罪地下組織。在我們的研究中，我們注意到更早的名為“SimpleLocker”的Android惡意軟體也有和GM BOT、SlemBunk相似的程式碼框架。然而，SimpleLocker有不同的目的：從受害者處索要贖金。在安裝到一個Android裝置以後，SimpleLocker會掃描裝置的特定檔案型別，對它們進行加密然後向受害者索要解密的贖金。在SimpleLocker出現之前，也有其他的Android惡意軟體會將螢幕鎖住；但是SimpleLocker是第一個Android上的檔案加密型的勒索軟體。

我們知道的更早的關於SimpleLocker的報告是ESET發表於2014年6月的（Links）。然而，我們也在我們2014年5月的惡意軟體資料庫中發現了一個更早的樣本(SHA256 edff7bb1d351eafbe2b4af1242d11faf7262b87dfc619e977d2af482453b16cb)。這個APP編譯的時間是2014年5月20號。我們把這個SimpleLocker的樣本和其中一個SlemBunk的樣本(SHA256 f3341fc8d7248b3d4e58a3ee87e4e675b5f6fc37f28644a2c6ca9c4d11c92b96)用比較GM BOT和SlemBunk的方法進行了比較。

下圖展示的是兩個樣本程式碼結構的比較。值得注意的是這個SimpleLocker的變種也有主元件ServiceStater和MainService，這兩個也都被SlemBunk所使用。然而，這裡的主服務的目的不是監視程式的執行並進行釣魚來獲取銀行資訊。SimpleLocker的主服務元件會掃描裝置來查詢受害者的檔案，然後會呼叫檔案加密類來對檔案進行加密進而進行勒索。SimpleLocker程式碼中主要的不同如下圖紅框所示：AesCrypt和FileEncryptor。其他共同的類包括：

  • Main, 兩個樣本中的啟動的activity。
  • SDCardServiceStarter，另一個receiver監視MainService的狀態，當它死掉之後會把它重啟。
  • Tor and OnionKit，第三方的lib庫檔案用來進行私密通訊。
  • TorSender, HttpSender and Utils，支援類來提供程式碼以進行CnC通訊，以及收集裝置資訊。

最後，我們定位到了另一個2014年6月的SimpleLocker樣本(SHA256 304efc1f0b5b8c6c711c03a13d5d8b90755cec00cac1218a7a4a22b091ffb30b)，大約在第一個SimpleLocker樣本被發現兩個月之後。這個新的樣本沒有使用Tor來進行私密通訊，但是和之前的SlemBunk樣本(SHA256: f3341fc8d7248b3d4e58a3ee87e4e675b5f6fc37f28644a2c6ca9c4d11c92b96)的5個主要的元件有四個是相同的。下圖展示了兩個樣本的程式碼結構的比較。

正如我們在上圖中看到的那樣，新的SimpleLocker樣本使用了和SlemBunk相似的打包機制，把HttpSender和Utils打包到了名叫“utils”的子包中。它也新增了兩個其他的最初只在SlemBunk中看到的主要元件：MessageReceiver和MyDeviceAdminReceiver。總的來說，這個SimpleLocker的變種木馬和SlemBunk在5個主要元件裡有4個是相同的。

下圖展示的是上個例子中MessageReceiver的主要的程式碼，來證明SimpleLocker和SlemBunk基本上使用了相同的程式和邏輯來和CnC伺服器進行通訊。首先，MessageReceiver類會先register來處理收到的短訊息，這些短訊息的到達會觸發onReceive方法。正如圖中所示，這裡的主邏輯基本上是和SimpleLocker和SlemBunk一樣的。他們首先會從應用偏好設定中讀取一個特殊的鍵的鍵值。這個鍵的名字和共享的偏好設定對於這兩個不同的惡意軟體家族來說是一樣的：鍵名為“CHECKING_NUMBER_DONE”，偏好設定名為“AppPrefs”。下面的步驟呼叫retriveMessage方法來檢索短訊息，接下來會把控制流傳到SMSProcessor類。這裡唯一的不同就是SimpleLocker新增了一個額外的方法processControlCommand來進行控制流傳輸。

SmsProcessor類定義了惡意軟體家族支援的CnC命令。通過對SmsProcessor的觀察，我們發現了更多的證據證明SimpleLocker和SlemBunk是有相同的起源的。首先，SimpleLocker支援的CnC命令實際上是SlemBunk支援的命令的子集。在SimpleLocker中，CnC命令包括“intercept_sms_start”、“intercept_sms_stop”、“control_number”和“send_sms”，所有的這些都在SlemBunk樣本中出現過。並且，在SimpleLocker和SlemBunk中都有共同的字首“#”在實際的CnC命令前。這也是SimpleLocker和SlemBunk有相同起源的非常重要的證據。

MyDeviceAdminReceiver類的任務是請求裝置管理員許可權，這會讓這些惡意軟體很難被移除。SimpleLocker和SlemBunk在這個方面極其類似，支援一套相同的裝置管理相關函式。

我們可以發現這些SimpleLocker和SlemBunk的變種木馬在主要控制元件上基本相同，和對相同的裝置支援性上的相似性。唯一不同的就是最後的payload，SlemBunk是為了對銀行資訊進行釣魚而SimpleLocker是為了加密檔案索要贖金。這也讓我們相信SimpleLocker和SlemBunk來自於相同的作者之手。

0x03 結論

我們的分析確認這幾個Android惡意軟體家族擁有共同的來源。更多的研究可能會發現更多相關的惡意軟體家族。

網路犯罪地下組織的獨立的開發者在編寫和定製惡意軟體方面是很熟練的。正如我們所知，帶有特殊或者多樣化目的的惡意軟體可以建立在對一些通用功能的共享程式碼上實現，比如獲取管理員許可權、啟動以及重啟服務、以及CnC通訊。

隨著GM BOT程式碼的洩露，基於這些程式碼定製的Android惡意軟體家族必然會增多。

0x04 Reference

相關文章