Ransomware Cerber Analysis
Cerber是一個可執行程序，它的感染后行為沒有CryptXXX這么隱蔽，可以說分析它的行為并不困難，但是它對內部數據的保護比CryptXXX做的好。例如:?我可以寫一個簡單反向算法就可以將CryptXXX中的所有加密數據提取出來，但是對于Cerber它顯然在對內部數據的保護上下足了功夫，但這并沒有阻擋我提取出它所有的內部數據。下面會詳細的分析它如何保護內部數據的邏輯。
還需要了解的是，Cerber是C語言實現的，并且它并沒有使用微軟的運行庫，換句話說它沒有采用微軟的編譯器，很有可能是Intel的編譯器或者是Cross-Compiler的gcc，我不確定。能夠肯定的是2點，沒有采用微軟編譯器，沒有使用C++標準庫。
2016-7-8
更新一下，我原本通過分析CryptXXX，感覺CryptXXX的邏輯設計的非常巧妙，它的感染方式被分散到很多個Export函數中。現在通過最新對Cerber的分析，發現Cerber也是設計的非常巧妙，它去做一些具體的操作時會調用其它命令行進程隱蔽自己。可以看出作者對windows系統的理解程度非常之深，應該是個高級玩家。
CryptXXX有各種設計精美的Blackmail，它們是Html，Bmp，Txt，有2個web服務器節點，與web的交互非常頻繁，相互做backup。維護這些都需要人員和精力，它很像是一個團隊在做。
Cerber更像是一個人在做，它的勒索頁面很簡單也不美觀，它也沒有與web交互，應該是沒有精力維護web站點，或者更好的隱藏自己。但作者應該是個windows資深玩家。
為什么這么講，因為我發現cerber會給自己提權，也會去check UAC當前的狀態，還用了很多windows的內置變量（%xxxx%）這種形式的，我感覺作者以前就是做病毒的。
Global Data Structure
| Named | ImageOffset | Size | Description |
| g_lpModuleFullPath | 0x41B760 | 4 | Cerber所在的當前目錄加文件名 |
| g_lpModulePath | 0x41B440 | 4 | Cerber所在的目錄 |
| g_pAddrContainMeta | 0x41B43C | 0x124 | 一個數據結構包含Meta信息 |
| g_hEvent | 0x41B438 | 4 | 全局Event，手動Set初始無信號 |
| g_szCerCoProtMutex | 0x41B648 | 4 | 全局Mutex的name |
| g_hHeap | 0x419A50 | 4 | 全局對象，私有堆句柄 |
| g_dwCurrentPID | 0x419A54 | 4 | 當前進程ID |
| g_dwImmMap | 0x419A3C | 0x10 | 一組常量，用于計算字符串 |
| g_bEncryptDone | 0x41BF61 | 4 | 加密是否完成標志 |
| g_hCryptProv | 0x41A168 | 4 | cryptographic service provider |
| g_szModuleFileName | 0x41B970 | 4 | 當前進程的文件名 |
| g_tedGlobalMeta | 0x41A0F8 | ? | 全局Meta數據結構 |
| g_bMultiThread | 0x41A12C | 4 | 全局標志，是否多線程加密 |
| g_dwMaxBlockSize | 0x41A14C | 4 | 最大塊的大小 |
| g_dwMaxBlocks | 0x41A12D | 4 | 最大塊數量 |
| g_dqMinFileSize | 0x41A138 | 8 | 最小文件大小 |
| g_dwRsaKeySize | 0x41A154 | 4 | RsaKey的大小 |
| g_Cerber_key_place | 0x41BEB8 | 4 | ? |
| g_pJsonObject | 0x41A134 | 4 | 全局json對象 |
| g_pfnIsWow64Process | 0x41BFFC | ? | API |
| g_InitEnvpPrograms | 0x41BFF8 | 4 | 判斷以下4個全局變量是否初始化 |
| g_envpPCPFile | 0x419AA4 | 4 | %CommonProgramFiles% |
| g_envpPCPW6432 | 0x419AA8 | 4 | %CommonProgramW6432% |
| g_envpProgramFile | 0x419AAC | 4 | %ProgramFiles% |
| g_envpProgramW6432 | 0x419AB0 | 4 | %ProgramW6432% |
| g_dwStopReason | 0x41952C | 4 | 程序不執行的原因 |
| g_bStartNoParam | 0x41BF60 | 4 | 標志是否沒有命令行參數 |
| g_lpNewExtension | 0x41BC98 | 4 | 加密后新的擴展名 |
| g_szWatchdogMutex | 0x41BB78 | 4 | Watchdog的mutex |
| g_byteDebug | 0x41A12E | 4 | 全局的調試標記，打開可以在DbgView中收到調試信息 |
| g_byteNetWork | 0x41A12F | 4 | 設置為1加密網絡文件 |
| g_AvgReadBytes | 0x41A150 | 4 | 平均每個塊的Bytes數量 |
Meta數據機構
包含一個初始化的臨界區變量，一個當前進程PID，當前進程的TID。
Export Function
| funcName | ImageOffset | Description |
| Start | 0x406BED | EP 沒有什么特別，PE的主入口 |
| RSA Key |
| LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUlJQklqQU5CZ2txaGtpRzl3MEJBUUVGQUFPQ0FROEFNSUlCQ2dLQ0FRRUF2a3R5NXFocUV5ZFI5MDc2RmV2cAowdU1QN0laTm1zMUFBN0dQUVVUaE1XYllpRVlJaEJLY1QwL253WXJCcTBPZ3Y3OUsxdHRhMDRFSFRyWGdjQXAvCk9KZ0JoejlONThhZXdkNHlaQm0yY29lYURHdmNHUkFjOWU3Mk9iRlEvVE1FL0lvN0xaNXFYRFd6RGFmSThMQTgKSlFtU3owTCsvRytMUFRXZzdrUE9wSlQ3V1NrUmI5VDh3NVFnWlJKdXZ2aEVySE04M2tPM0VMVEgrU29FSTUzcAo0RU5Wd2ZOTkVwT3BucE9PU0tRb2J0SXc1NkNzUUZyaGFjMHNRbE9qZWsvbXVWbHV4amlFbWMwZnN6azJXTFNuCnFyeWlNeXphSTVEV0JEallLWEExdHAyaC95Z2JrWWRGWVJiQUVxd3RMeFQyd01mV1BRSTVPa2hUYTl0WnFEMEgKblFJREFRQUIKLS0tLS1FTkQgUFVCTElDIEtFWS0tLS0tCg== |
解密Cerber的內部數據非常麻煩，它用了很多層技術防止提取出它的內部數據，這些數據雖然可以在調試時動態的跑出來但是對于靜態分析代碼效率太低下。因此我實現了這個解密算法。
| The assembly list was implemented by me |
| ?decrypt |
| The file be generated automatically |
| ?GenerateCodes |
下面是解密后與解密前的數據，解密之前的數據我并沒有 dump出來，因為我累計在這部分已經花去了超過24個小時（包括編寫匯編算法，抽取腳本，分析等），我不想再花更多的時間完善它（后來強迫癥犯了，提供了一個diff版方便看代碼）。
| Encrypt | Decrypt |
| ?encrypt | ?decrypt |
通過分析decrypt.txt文件，可以發現cerber隱藏的很多細節，包括我并沒有發現的細節。因此解密內部數據這項工作應該更早的展開。
通過閱讀解密后的數據，可以了解它使用了那些技術。挑選一些主要的寫在下面。
| select * from %s | 難道有內部數據庫，這是不可能的，有可能是應用了WMI。 |
| FirewallProduct | 這個好像不言自明 |
| AntiVirusProduct | |
| cerber_startup_fake_service | Fake？ |
| wireshark.exe | 看起來會反調試反監控，但是事實上好像沒有work |
| dumpcap.exe | |
| ollydbg.exe | |
| SOFTWARE\Oracle\VirtualBox | 看起來是虛擬機檢查，不過貌似也沒有work |
| VBoxMouse.sys | |
| VMWARE | |
| SOFTWARE\VMware, Inc.\VMware Tools | |
| CERBER_WATCHDOG_PROTECTION_MUTEX | 這些串放到這里讓人一看就知道他的行為，如果我寫我會Debug和Release分別放置不同的值 |
| CERBER_CORE_PROTECTION_MUTEX | |
| CERBER_STATISTICS_PROTECTION_MUTEX | |
| bcdedit.exe
/set {default} recoveryenabled no | 這個…?很賤 |
| Software\Microsoft\Windows\CurrentVersion\Run | 看起來要自啟動 |
| AutoRun | ? |
| ? | ? |
這是一個Json格式文件，被解密后釋放出來。是一個配置文件
| The file type of JSON which Extracted from decrypt |
| ?config |
這個Json后面會釋放出3個勒索文件出來
| ?help_cerber注意，這個包沒有病毒，但是在Windows10上會被Windows Defender警告，因為它檢測到模式匹配 |
主程序行為詳細分析。
先看一下下面鏈接的代碼:
start
Cerber程序被執行后，會先解密一個內部數據并計算一個四字節的值存放到全局變量中。然后通過當前進程的Pid創建一個全局唯一的Mutex命名字符串并用它構造命名的Mutex對象(MSCTF.Shared.MUTEX.575906ab)。
緊接著將當前全路徑提取出來，同時將文件名去掉只保留路徑，并把這兩個值保存到全局變量中去。
接著，開始嘗試啟動新的cerber進程。這個過程比較隱晦，它先枚舉系統所有的窗口站，并查找有沒有交互式窗口，如果找到了，將這個交互式窗口鏈接到當前進程，然后注冊并啟動一個Windows Service，這個服務只做一件事情，就是不停的嘗試再啟動一個Cerber進程。如果啟動服務沒有成功，那么就直接創建一個Cerber進程，這個過程也很麻煩，它會先獲取當前活動的SessionID，并進而獲得用戶的Token，用用戶的身份去創建一個新的Cerber，無論兩種方法只要創建成功，那就不會返回，進程退出。
TED_CreateCerberAgain
CB_CreateThreadOnSCM
TR_CreateProcessUtillSucess
TED_CreateProcess
wrap_CreateProcessAsUser
這是程序的Self-Spawn流程。
?
?
?
解密內部數據流程
在進入真正搞破壞之前，程序還有些準備工作要做，其中就包括從自身的資源文件中提取一個Json文件出來，并用一個JsonParser生成一個Json對象出來。這里有可能使用了第三方的Json解析庫，我不確定是Jsonc還是Jansson。因為我已經把Json內部的一些方法分析出來了，才判斷出那是在構造一個Json對象，因此如果早一點介入調查第三方庫會效率更高一些。
Ok，回到初始化JsonObject的部分，首先程序會把自己Image中的資源段文件讀取出來，然后通過自定義的算法計算出Json文件的串并Hold在內存中。下面我來分析一下這個過程。
首先，它會用一個神奇的算法解密出制定的字符串，這個神奇的算法被普遍應用于解密字符串在這個程序中（我已經實現了這個算法，1000行匯編代碼）。
前面我說過cerber對內部數據的保護比CryptXXX做的更好就是由于它的解密內部數據的算法需要固定3個值才能解密出對應的數據，而CryptXXX的算法是固定，只要有輸入就可以解密內部數據。
PCTSTR __cdecl TED_MakeRealTString(BYTE *byteUnknown, int nResSize, DWORD dwHex, char bUseWStr);
TED_MakeRealTString
上面是解密內部數據的func原型，其中需要固定的數據有保存在rdata中的字節，字節長度，一組解密用的key(4字節16進制數據)。
這個解密函數非常復雜，首先如果是第一次調用需要要進行一下初始化，工作包括將內部數據的鏈表頭指向空，初始化meta信息，meta信息中包括了臨界區變量，進程PID，TID。
然后，根據傳入的rdata中的字節和字節長度計算一個CRC，然后遍歷鏈表，如果匹配到了相同的CRC，就把當前鏈表中的item取出來，返回保存在item中WStr或者Str，這個是根據上面原型的第四個參數指定的。
如果通過CRC沒有找到數據，那說明數據還沒有被緩存，執行計算過程。首先為鏈表分配一個新的節點，并把CRC放到新的item里面，然后開始執行計算。
計算的過程也很復雜，首先在棧上構造一個ASCII碼表，然后把輸入的字節解釋稱0-255的整數數組，并用一個會自動循環并且最大值不會超過輸入字節長度的索引值不停的循環的取出輸入數據中的值并當成整形與ASCII碼表中整數計算出一個可變的數值，這個數值會與ASCII碼表中的數據交換，經過這樣循環的處理，會因為輸入的不同得出不同的結果。（復雜代碼用語言描述太難了，還是看代碼吧）
TED_CalculateSpecialString
然后，它用被交換，或者說是擾亂過的ASCII碼表與輸入的加密后的數據做異或操作（一個復雜的異或操作，加減偏移什么的），計算出Real的數據出來。
我這里講的是它解密出了一塊Json的數據，下一步還要解析這個Json數據把它轉換成內部的數據結構。
鏈表在這里的作用是緩存內部數據。
構造Json Object流程
在生成Json對象之前首先要了解Json的基本數據類型，json共有5種基本數據類型，它們是邏輯值，字符串，數值，數組和對象。其它信息如果想了解就去google一下吧。
程序首先構造了一個json對象：
TED_GetJsonMem
然后把這個對象和json串一起送入Parser中，Parser根據輸入的Json會去填充這個JsonObject。這像是某一種第三方Json Parse庫，因此我沒有必要繼續分析它的作用。看一下就知道是在解析Json。
JSON_Parse
看的出來，這個JSON_Parse被多個函數調用，但我們這里只需要關注Start這條線就可以了。
因為他上面調用它的生成Json對象的方法是一個通用方法，程序的其它位置會調用它來生成其它的Json對象。
?
?
TED_GenerateJsonObject
TODO：JsonStructure
JsonObject被初始化完畢后，在程序中提取配置信息等操作就由相應的操作函數來完成。這個對象是在內存中分配出來的，因此在全局數據區是發現不到它的。這個對象會再接下來的程序生命期中被多次使用到。
配置全局變量
接下來程序需要初始化一些全局數據成員，通過從Json中提取出key對應的value。這些全局變量是加密用戶數據所需要指定的配置信息，它們包括：多線程加密標志，最大塊尺寸，最大塊數量，最小文件尺寸，RSAkey的size。
?
接下來，程序要進行一些加密前的檢查工作，它先要去檢查一下指定的注冊表位置，第一次執行時這個位置是空的，因此這段code會直接返回，還不會開始加密用戶的數據。
“Printers\Defaults\{89873163-8DC1-7563-E594-6622BDBB1978}”這個注冊表位置會被檢查，如果不是第一次運行，在這個位置會有幾堆數據，這些數據包含是一個被序列化的Json對象，一組RsaKey，那么程序的就會解析這個Json對象，解析后的Json對象指針會被放到g_pJsonObject（看最開頭有列表）這個位置，并且程序會提取出RasKey并計算一個hash并放到全局變量中去，完成這些工作后程序返回。
上面這個過程就是加快操作的功能，如果從注冊表中提取不到Rsa信息，那么就從全局的json對象中構造，首先從json對象中提取一個用來加密的Key，這個key實際上可以從資源文件中提取出來(最上面有列出)。然后把這些信息寫到注冊表中，讓下一次操作可以從注冊表中提取數據。整個的流程如下：
TED_GetCerberKeyFromRegister
完整的加密配置準備工作的流程如下：
TED_PrepareEncrypt
CoreProtectionMutex
接下來程序初始化了一個全局mutex，這個mutex被Cerber當作Core Protection Mutex，然后創建了一個。
然后還會創建一個全局的Event。
GlobalMeta
然后程序開始分配一些內存，為創建全局的數據結構，這個結構包含一個meta信息，一組句柄，還有標記句柄數據中保存了多少句柄的數值。Meta信息是另一個數據結構，包含當前進程Pid，線程的tid，以及一個臨界區對象。
struct tedStruData {
int dwCount;
tedGlobalMeta meta;
HANDLE* pObjHandle[64];
};
緊接著，他會創建一個線程，并把這條線程加入到全局數據結構的句柄數組中去。這條線程啟動了之后會創建一個隱藏的窗口，這個窗口的窗口過程接收END_SESSION消息，當收到這條消息后，會對全局Event設置信號，這個事件是為了保證系統中其它的Cerber進程能夠有效的退出。
CB_WindowProc
接下來，程序處理一下命令行參數，因為程序是命令行應用，第一次執行時不帶參數，當啟動后，會釋放程序內的加密數據，這些數據包含了很多命令行參數。當cerber spawn一堆cerber的時候它們都會帶一些特殊的參數進來，在這里，程序的行為將發生變化。它的核心邏輯就在這里了，分析這部分代碼還是很有收獲的，提權功能，關閉UAC功能，反AV產品功能，反虛擬機功能，判斷是不是Admin功能，在64位操作系統上禁用文件系統重定向等在這里被大量使用，也導致了程序在不同的平臺上行為不一樣，學習到很多病毒的做法。也正是因為分析了這部分代碼，我才感覺作者在windows領域浸淫已久，很牛逼。這些技術CryptXXX并沒有出現。
?TED_ProcessCommand
ProcessCommand里面的內容非常多，一一展開很費心力，我們先跳過這里，看看后面做了什么，最后在回過頭看這部分。
2016-7-12 back to here
這個Func被重命名為TED_ProcessCommand，因為程序會根據不同的執行流選擇做具體的操作，而具體的操作都是通過創建自身的一個副本，并提供一些不同的參數從而實現了同一個程序的不同行為，因此代碼中需要有一個解析并處理Command Argv的地方，這個地方就是ProcessCommand函數。
這個函數被調用后，首先嘗試啟動調試權限，然后會判斷當前的啟動路徑是不是一個特殊的路徑(C:\Users\Administrator\AppData\Roaming\{64E3EBE0-DAE1-314A-731D-B7440DC4E389})在我機器上如上述路徑，如果不是，就把程序拷貝到這里面去，并創建一個Process再次執行，當前Process退出。
如果是的話，接下來會去判斷傳入的參數數量，進入不同的if塊中，這里有3種選擇，沒有參數，有2個參數，以及超過3個參數的條件。
沒有參數的情況是直接執行本程序，這時候他會去簡單當前是不是Admin的權限，如果是它嘗試用管理員的身份重新啟動cerber并帶上-eval {dwCurrentPid}參數，但是它在這么做之前會先檢查一下UAC的狀態，如果UAC沒有工作，那么它會這么做。如果UAC正在工作中，它會用cmd去啟動當前的Process的鏡像文件。{cmd /d /c start c:\tmp\cerber.exe –eval pid}.?這個原因導致調試困難。
如果程序啟動后被傳入了2個參數，這里有好幾個可選項（eval，shadow，watchdog，stat，antiav）。如果shadow，那么將刪除卷快照，并將啟動恢復設置為no。
TED_PC_shadow
如果參數是watchdog，程序先初始化watchdog的專用mutex，先啟動一個watchdog創建線程，創建watchdog process，然后這個線程會每隔1秒監控watchdog process是否始終活動，如果超過4秒watchdog process仍然活躍，那么久殺了這個process再創建一個，這么做是不是為了防止watchdog process被輕易的發現？
TED_PC_watchdog
TR_Watchdog
如果不是第一次運行，那么watchdog可能已經被創建了，程序打開watchdog的全局mutex，如果發現mutex的句柄不存在，說明程序可能出現了問題，例如被調試等，那么程序會繼續檢查Core Protection Mutex在不在，如果也不存在，那么殺死所有在系統中的cerber進程，隱蔽它的行為。
如果參數是antiav，它會檢查是不是具有管理員權限，然后執行AntiAVProduct函數，內部邏輯異常復雜，涉及到權限，SID，Boot等設置，放代碼讀下不解釋了。
TED_AnitAv
如果參數是stat，那么它開始執行真正的加密工作，在開始加密之前，需要進行一些準備工作。首先把json中的encrypt對象中的數據全部load到內存中，包括一組擴展名列表，然后打開注冊表Printers\Defaults\{89873163-8DC1-7563-E594-6622BDBB1978}，在這個位置把RsaKey取出來，如果取不到，它會先從內存中把Key給弄進去，下次就會取到Key了。
然后，進入Encrypt函數，開始執行真正的加密工作。這里有個debug標志，如果把這個標志打開，會把一些調試信息寫到文件中，可能得到一些有效的信息。如果json文件中指定多線程加密，那么就會根據指定的數量創建多條線程進行加密。
TED_Encrypt
TR_DoEncrypt
TED_EncryptData主要加密函數，入參是路徑+文件名，加密的核心算法就在這個func里面
在加密之前還有一寫邏輯用來枚舉所有驅動器，網絡驅動器的，把需要加密的磁盤遞歸的加入一個鏈表中（這個鏈表數據結構很復雜，我很想弄出來，不過由于太耗費時間放棄了）。
TED_EnumDevice?枚舉所有可以訪問并有寫權限的驅動器
TED_RecursionFolder?遞歸的將所有文件加入鏈表
退出部分
經過上面的邏輯后，程序會拋出很多的Process，函數返回后用戶的數據也已經被加密了，剩下的部分是準備推出部分，這部分不是特別重要，但是它卻展示了程序內部數據結構的構成，以及如何管理大量的句柄。
這次先放代碼，看后分析
TED_PrepareLeave?主調
TED_WaitAllObject?具體
主調函數先進入臨界區，然后調用waitAllObject去等待所有的句柄相應。句柄中大量的process和thread。WaitAllObject函數已經被我分析好了，這部分代碼很有意思，理解它需要有一些領域知識，如果沒有寫過高并發服務器的話，估計很難看得懂這部分代碼（指未翻譯之前的代碼）。
首先有一個背景知識，就是一個WaitForMutliObject句柄組上限是64個，超過這個數量就沒法管理了（不信可以去google）。那么如果需要在wait中管理超過64個句柄怎么辦，有一個辦法，類似虛擬地址映射（頁表，頁目錄），可以創建一些管理線程，這些線程每一個管理另外64個句柄，這樣可以無限放大（二級，三級這樣）。有了這些知識再看代碼就清晰了，可以讀一下我翻譯過的代碼。
繼續往下，都是一些釋放操作沒什么好說的。最后如果加密完成，它要通知其他系統中的cerber進程退出，這些進程可能是上面wait不到的。反正要退出了，這里也比較暴力，枚舉所有cerber然后調用Terminate。后面還有一個force的做backup，是通過cmd.exe調用taskkill來殺。最后在自殺。放一個小片段吧。
SR_start
?原文地址：?http://ec2-52-196-167-189.ap-northeast-1.compute.amazonaws.com/wordpress/index.php/2016/07/15/cerber-analysis/
與50位技術專家面對面20年技術見證，附贈技術全景圖總結
以上是生活随笔為你收集整理的Ransomware Cerber Analysis的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Ransomware Locky Ana
- 下一篇： Ransomware CryptXXX