導語：2016年2月19日，IBM XForce的研究員發布了一個情報報告，這份報告聲稱GM BOT的源代碼在2015年12月被泄漏到了一個惡意軟件論壇上。GM BOT是一個復雜的安卓惡意軟件家族，它出現在2014年末俄語地區的網絡犯罪地下組織。

2016年2月19日，IBM XForce的研究員發布了一個情報報告，這份報告聲稱GM BOT的源代碼在2015年12月被泄漏到了一個惡意軟件論壇上。GM BOT是一個復雜的安卓惡意軟件家族，它出現在2014年末俄語地區的網絡犯罪地下組織。IBM XForce同時還發現Banskosy，MazarBot，以及惡意軟件Slembunk。實際上也是GM BOT的變種，包括Banskosy，MazarBot，以及FireEye最近提到的惡意軟件Slembunk。

GM BOT中的很多功能都是針對Android用戶的,包括攔截他們的短信。它允許攻擊者控制目標設備,還能根據用戶的手機,定制假的手機界面。

簡而言之, GM Bot這樣的手機銀行木馬對于罪犯來說，簡直就是一種一站式的、提供各種欺詐手段的商店。

1.他們仿造銀行應用程序的界面，使用假的界面覆蓋原先的銀行界面，從而竊取用戶憑證和支付卡的信息。 2.他們控制設備的SMS繼電器，然后竊聽、截取并且發送SMS消息。????????? 3.他們還可以將電話轉接給遠程攻擊者。????????? 4.他們也有間諜軟件的功能,可以通過遠程命令控制設備。

目前，GM Bot又把目標瞄準了MobilePay（丹麥銀行的移動支付平臺MobilePay）和Nem ID（丹麥的一種雙因素認證系統）。本文通過靜態分析和動態分析來對GM Bot的源代碼打包過程進行剖析。

我們看到即使使用基本的靜態分析，我們也可以分析出 GM Bot的惡意意圖也可以很容易地實現，而且通過一個微小調試我們可以快速獲得可讀的源代碼。

背景

要了解網絡安全的，我們就有必要認真了解一下移動惡意軟件是如何運作的。

本文就列舉一些例子，來對它們的惡意運作過程進行演示。

SHA256:?44ed4bbd5cdc13c28992c16e99a7dc58f5f95463e889dd494a433549754f7863 MD5:?da88bdcb3d53d3ce7ab9f81d15be8497

如果您還想要瀏覽此示例，可以通過google快速的搜索這些哈希值可能導致的后果。雖然分析人員已經有了這些源代碼，但不清楚如何它們是如何實現的。有消息說這些代碼已經被打包，但是還沒有關于如何解壓縮的分析的信息。

這篇文章就是要分析這些源代碼解壓縮的過程，希望能為的其他人提供一些提示。本文的分析過程分為以下五個階段：

1.公共分析 ：首先我們可以使用現有的公共信息來源來進行查找，看看目前的分析到了什么階段以及進行了哪些方面的分析。

2.靜態分析：我們可以從找到的實際樣本中進行分析，而不是在模擬環境中分析。

3打包調試：假設樣本被打包并阻止我們對其分析，我們如何調試解包器以了解樣本正在加載/運行的內容。

4.DEX文件提取和反編譯：一旦我們實現了解包器的功能，我們如何對其進行反編譯。

5.功能和動態分析 ： 一旦我們提取和反編譯了代碼，我們就會在安全模擬環境中看到GM Bot是如何進行工作的。

第一階段，公共源分析

首先讓我們看看我們在這個階段可以找到什么？在Virus Total將其已經被標識為惡意產品，然而，我們還注意到，通過啟發式分析所檢測出的這些惡意軟件是指所有含有“惡意代碼”的產品。這種檢測最初是由Ganga Man在暗網論壇上建立和銷售。

第二階段，靜態分析

首先，我們要使用APK工具解壓縮APK文件。這將解壓縮內容，以及將DEX文件中的代碼拆分成Smali：

apktool?d?da88bdcb3d53d3ce7ab9f81d15be8497.apk

這個結果可以在下面看到，該工具還提供了一個可讀的AndroidManifest.xml文件版本。

第一個停止是看看Android清單文件，應該提供應用程序的組件和請求的權限的概述。

清單分析 – AndroidManifest.xml

初始分析顯示惡意行為已經獲取了廣泛的權限，包括以下權限：

控制所有SMS消息（發送，接收，讀取，寫入，刪除） 列表運行應用程序 讀取手機的狀態，聯系人，SD卡數據 請求是設備管理員，使得能夠在不向用戶發出警告的情況下遠程擦除設備

主應用程序，活動（15）和服務（2）的引用類文件的摘要視圖如下所示：

此外，我們看到另外4個類映射為廣播接收器，它將處理事件消息（Android系統Intents），如下所示：

從上圖我們可以看到應用程序如下：

在手機通電時執行代碼（自動啟動應用程序）

當設備管理員被授予，請求或接收到禁用管理員的請求時接收通知（從而干擾或阻止用戶啟用它）

接收新的入站SMS的通知 – 具有高優先級標志，以確保代碼可以首先攔截它，并可能停止任何進一步的警報（可以用于竊取2FA令牌）

在進行任何反編譯之前，我們要做的就是探索APK中的其他文件的線索。

比如以下文件：

文件：assets / fytluah.dat

一個沒有立即明顯格式的二進制文件。可能的代碼在運行時未加密/解壓縮？

文件：res / values / strings.xml

應用程序的英語字符串，如下所示：

字符串清楚地表明此惡意軟件的目標是獲取受害者的信用卡信息。如此之外，我們還發現了以下線索：

有趣的是，這里的資源鍵都是英文，表明原始開發者可能是英語區域

盡管這個資源文件是用于英語編寫的，但仔細看會發下其中有一些特定的字符串是丹麥語，

除了英語字符串，我們還看到其他幾個目標國家：

文件：res / values.xml

此文件包含國家/地區代碼列表，特別是“非vbv”這組。這被理解為意味著他們不使用“通過簽證驗證”過程，該過程用于在在線購買期間強制執行額外的驗證檢查。很可能攻擊者會試圖通過惡意軟件獲取額外的VBV憑證（ 是VISA國際組織為提高信用卡網上支付的安全性,保障客戶網上支付安全,維護客戶利益而共同推出的一項安全驗證服務），以允許在線購買卡詳細信息（或避免這些國家）。

目錄：res / drawable

圖片和圖標包括：

丹麥語“Nem?Id”的示例照片?-?https://en.wikipedia.org/wiki/NemID 丹麥銀行移動支付的圖標 萬事達卡安全代碼 通過簽證驗證的圖標 Google?Play Flash圖標（主應用程序圖標） Whatsapp

此外，有png圖像前綴“overlay_”，表示欺詐覆蓋活動可能使用。

反編譯為Java源代碼

接下來，我們嘗試將DEX文件反向工程恢復為原始的Java源代碼。為此，我們使用dex2jar如下將DEX文件（在APK中）轉換為Java類文件存檔：

Dex2jar?da88bdcb3d53d3ce7ab9f81d15be8497.apk

然后可以使用JD-GUI解壓縮生成的jar文件，如下所示：

java?-jar?../../jd-gui-1.4.0.jar?da88bdcb3d53d3ce7ab9f81d15be8497_dex2jar.jar

我們在JD-GUI中看到的結果java類顯示應用程序中只包含4個java類。這與我們在應用程序清單中聲明的16個不同類形成了直接對照。確認必須有在運行時動態加載的附加代碼 – 這很可能是這四個類實際上是一個解包器。

檢查代碼，我們看到它被嚴重混淆，并且已經被制定以防止干凈的反編譯代碼。除此之外，我們可以通過檢查在應用程序首次執行時導入（因此使用）的系統類，開始了解這四個類的功能。

從JD-GUI導出java源并解壓縮到新文件夾后，我們可以從這些文件中提取導入的類：

find?.?-type?f?-exec?grep?"^import"?{}?\;?|?sort?–u

我們可以從中找到如下的分類

分類	導入類
com.igcfse.enscbo.a	com.igcfse.enscbo.b
com.igcfse.enscbo.a	java.io.RandomAccessFile
com.igcfse.enscbo.a	java.lang.reflect.Constructor
com.igcfse.enscbo.b	android.app.Application
com.igcfse.enscbo.b	android.content.Context
com.igcfse.enscbo.b	com.igcfse.enscbo.a
com.igcfse.enscbo.b	java.io.File
com.igcfse.enscbo.b	java.lang.reflect.Field
com.igcfse.enscbo.b	java.lang.reflect.Method
com.igcfse.enscbo.c	android.content.Context
com.igcfse.enscbo.c	com.igcfse.enscbo.b
com.igcfse.enscbo.c	java.io.FileDescriptor
com.igcfse.enscbo.c	java.io.IOException
com.igcfse.enscbo.c	java.lang.reflect.Constructor
com.igcfse.enscbo.c	java.util.Random
com.igcfse.enscbo.wieroel	android.app.Application
com.igcfse.enscbo.wieroel	android.content.Context
com.igcfse.enscbo.wieroel	com.igcfse.enscbo.b

基本上我們用了一個非常小的庫被導入和使用。這些功能包括：

一般Android應用程序和上下文類（預期和所有Android應用程序需要） 文件相關類（紅色）?-?用于訪問，讀取和寫入本地文件 Java反射類（綠色）?-?用于創建新類和實例以及動態調用方法 這證實了這樣的假設，我們最有可能處理從本地文件資源解包它的可執行代碼的解包器。

第三階段：解壓縮調試

由于Java代碼不能被容易地反編譯（由于惡意軟件的開發者也會進行注入保護），我們將根據Smali匯編代碼調試可執行文件。 Smali是Dalvik虛擬機使用的DEX代碼的反匯編。

需要用于Android Studio的Smali / Baksmali插件，然后將Apktool的輸出作為新項目導入。我們接下來在三個類（a，b，c）中根據需要設置斷點：

具體如下：

a.smali（一個基于java.lang.reflect.Constructor實例創建的行）

b.smali（通過反射調用對象上的方法的行）

c.smali（與上述a.smali類似）

現在我們將應用程序安裝到模擬器（通過ADB，以確保它不會像在一些模擬環境中自動啟動）。

要啟用調試器連接到應用程序，我們在啟動應用程序之前執行以下操作：

通過在設置>關于設備中重復點擊內部版本號來啟用開發人員選項

在開發人員選項中，選擇“選擇調試應用程序”，然后選擇惡意應用程序 – “Adobe Flash”

在開發人員選項中，啟用“等待調試器”

現在從啟動器中啟動應用程序，將提示您附加調試器，

在Android Studio中，使用圖標附加調試器。選擇惡意應用程序進程。然后調試器在我們的第一個斷點處停止，如下所示：

注意，你現在應該設置一些變量來觀察 – 按照上面的設置v0到v10和p1到p3。我們的第一個斷點被擊中，我們看到我們將要通過反射執行一個方法。注意到我們還沒有調用newInstance（），我們可以假設這是調用現有的（加載）類 – 應用程序加載的四個之一，或一些其他Android框架類。

接下來，我們使用該方法強制進入，以查看它調用哪個方法（smali調試器看起來有點兒錯誤，我們現在不能看到傳遞的參數）。

初始調用獲取當前上下文對象，可能是從APK開始檢索本地資源。 我們現在允許調試器繼續并重復此模擬幾次以建立反射方法調用的流程：

Context?android.context.ContextWrapper.getBaseContext() //expected?2?arguments,?got?1?–?error?in?malware?code,?or?to?throw?off?debugging? //Several?more?of?these?not?shown IllegalArgumentException?java.lang.IllegalArgumentException(String?s) void?Java.lang.reflect.setAccessible(boolean?flag) File?android.app.getDataDir()//?returns?/data/user/0/com.kzcaxog.mgmxluwswb/app_ydtjqjava.io.File.getAbsolutePath()?ContextImpl?android.app.getImpl(Context?context)//filename?is?fytluah.datInputStream?android.content.res.AssetManager.open(String?fileName)

暫停在這里，我們可以看到代碼正在嘗試加載我們以前在靜態分析部分中標記為的文件。 繼續我們看到文件被讀取，可能被解密，然后作為一個jar文件再次寫出：

int?android.content.res.AssetManager.read(byte[]?b) //className?=?java.io.FileClass?java.lang.Class.forName(String?className)? //args?=?String?“/data/user/0/com.kzcaxog.mgmxluwswb/app_ydtjq/gpyjzmose.jar” T?Java.lang.reflect.Constructor.newInstance(Object..?args)? void?java.io.FileOutputStream.write(byte[]?b)?#25 void?java.io.FileOutputStream.close()

最后調用DexClassLoader來將附加代碼加載到系統中：

ClassLoader?java.lang.Class.getClassLoader() //className?is?dalvik.system.DexClassLoaderjava.lang.Class.forName(String?className)

查看DexClassLoader的API，我們可以看到它需要兩個參數： 要加載的文件的位置，以及一個可寫區域，它將用于為特定機器架構重新編寫優化版本的代碼，例如 Android運行時間（ART）。 有關這方面的更多信息，請參閱Android API文檔：

https://developer.android.com/reference/dalvik/system/DexClassLoader.html

第四階段：DEX提取和解碼

我們可以在下面的調試器中看到jar文件的確切位置，下一步是通過ADB命令行恢復這個文件。

執行類加載器后，通過ADB shell連接我們可以看到這兩個文件，原來的和DEX優化后的代碼：

我們將這些文件復制到/ sdcard /下載（+ chmod），然后將.jar文件拖到本地模擬實踐中，進一步使用adb pull分析。

提取jar文件我們找到classes.dex文件，重復此步驟，使用dex2jar將其轉換為jar文件并使用JD-GUI反編譯，現在我們就有這個惡意軟件示例的完整的源代碼了。

第五階段：動態和功能分析

首次安裝

在初始分析時，我們可以看到代碼庫與靜態分析中確定的泄漏源具有顯著的相似性。然而，也存在顯著差異，并且代碼已被模擬成為專門針對丹麥銀行MobilePay的應用程序了。

由于代碼基本上沒有混淆，現在將簡要介紹這個惡意軟件的關鍵功能，從第一次安裝開始。

首次安裝過程如下：

首先在安裝和執行時，應用程序將執行兩個主要功能。它最初將收集用戶數據的范圍，包括電話聯系人，所有SMS消息和其他密鑰數據，并將其發送到C＆C服務器。 C＆C服務器然后返回唯一的安裝標識符，然后唯一的安裝標識符被用于所有未來的通信以唯一地標識受損的設備。

其次，惡意軟件將使用戶接受軟件作為設備管理員。如果用戶拒絕請求那該軟件會被重新被觸發，最終大多數用戶將會選擇同意。有了這個權限，惡意軟件實現了兩個目標：

1.應用程序不能被用戶輕松地卸載，以保證不被取消設備管理員權限。嘗試執行此操作將觸發啟動覆蓋，以防止刪除設備管理員

2.在將來的某個時間點，一旦從電話竊取了另外的數據，C2服務器可以發出命令來擦除設備，移除感染的證據并將設備恢復到出廠狀態

包括每次重新啟動后，正在進行的操作

惡意軟件維護C2服務器的正常運行，這為攻擊者向設備發出特定命令提供了一種機制。每次運行包含安裝ID和當前屏幕狀態。前提是攻擊者會在用戶關屏時進行。

首先，我們看到了“鎖定”和“解鎖”手機的能力。這模擬了Android軟件更新屏幕，并有效隱藏了屏幕覆蓋后面發生的任何其他活動（例如發送，接收或刪除SMS消息）。此外，這可以用于禁用用戶，并且防止他們使用電話，而他們的帳戶或卡被實時泄密。

接下來，我們看到另一個功能，意圖攔截和轉發SMS消息到C2服務器，并專門試圖刪除他們曾經存在的證據，刪除它們。這用于竊取2FA憑證。

接下來從C2服務器的角度看，我們看到兩個“重置”命令。第一個，“軟”復位，用于重置內部標志以重新嘗試竊取Nem ID憑證。第二種是“硬”復位，執行并立即擦除器件數據。

最后，我們看到向攻擊者定義的移動設備發送任意SMS消息的能力以及向設備上的另一個應用程序啟動定制推送通知的功能。暫時不清楚這可以用于什么。

通過短信遠程操控

通過偵聽傳入的SMS消息，惡意軟件還可以觸發假的Android更新屏幕，然后截獲此信息，轉發并嘗試在消息到達電話時刪除消息。可以通過經由SMS傳遞到電話的定制的SMS命令消息來啟用和禁用該模式。

數據自動竊取

根據原始文章和靜態分析的許多指標，應用程序的主要目的是通過在合法應用程序之上執行覆蓋來竊取數據。惡意軟件針對三種特定的應用程序類別：

丹麥銀行的MobilePay應用程序，具體意圖竊取Nem ID憑據

觸發試圖通過自定義疊加層竊取信用卡詳細信息的應用

觸發竊取用戶移動電話號碼的嘗試的應用（可能用于觸發上述“管理”模式）

覆蓋丹麥銀行MobilePay的過程

在啟動MobilePay應用程序時，覆蓋嘗試竊取用戶的CPR號碼（唯一的社會安全類型id），移動號碼和Nem密碼。然后它要求用戶拍攝他們的Nem ID存折的照片，其中包含一次性使用代碼，攻擊者可以使用該代碼登錄到MobilePay（和其他丹麥語系統）并支付款項。

竊取信用卡詳細資料

在啟動目標應用程序之一時，根據啟動的應用程序，顯示具有可配置圖標的信用卡覆蓋圖。收集基本卡詳細信息后，應用程序將嘗試恢復用戶的Visa驗證密碼。然后將這些詳細信息轉發到C2服務器。

盜取電話號碼

最后，我們看到的目標是獲取用戶的電話號碼的功能，可能會通過獲得這些信息繞過2FA進一步對受害者帳進行攻擊。

總結

本文對GM Bot的變異似乎是僅僅針對于MobilePay應用程序這個變體的分析，但通過分析我們發現，一旦一個惡意軟件的源代碼被發布并且在網上能輕而易舉的搜到，那它被快速改變的可能性就很大。

MobilePay應用程序就是一個很好的例子，GM Bot源代碼一旦發布，復雜的代碼可以快速，輕松地被不太專業的開發者和一個成熟的黑客模式所應用，而且代碼庫變體的擴展變得更難以跟蹤和檢測。

一如既往，防止成為此類惡意軟件的受害者的最佳方法就是確保您的手機在安裝第三方應用程序時始終要保持審查權限請求 – 例如，它們是否與應用程序的使用說明一致等等。

本文翻譯自securityaffairs，如若轉載，請注明原文地址： http://www.4hou.com/technology/3051.html 與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的分析Android银行木马GM Bot的变异过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。