16895

作者：360QEX團隊

0x00 前言

在病毒查殺過程中，一直存在著攻與防的技術對立，惡意程序會采用各種方法躲避殺毒引擎的檢測，增加分析難度。360QEX團隊之前分別對JS敲詐者和宏病毒的隱藏與反混淆分享過相關內容，這次則分享一些AnglerEK的Flash樣本解密方法。

Angler EK攻擊包是當前最為著名的一個攻擊包，從出現至今，已經被大量用于網頁掛馬。由于Angler EK能夠整合最新被修復的漏洞利用代碼，甚至偶爾會出現0day的利用代碼，因而被視為最先進的漏洞攻擊包。

近兩年來，Angler EK大量使用Flash作為漏洞利用載體，往往Adobe剛剛曝光一個漏洞，就立即出現在了Angler EK攻擊包中。為了躲避殺毒軟件的檢測，Angler EK采用了多種方法加密Flash攻擊代碼，增加了檢測難度和安全人員的分析難度。

0x01 字符串與函數名的混淆

在ActionScript3中代碼調用的相關函數名稱和類名，均以字符串形式存儲在doabc字段中，所以為了規避針對調用函數名和類名的檢測，AnglerEK采用了getDefinitionByName函數，根據傳入的字符串參數轉換為調用對應的函數或者類，然后在將這些字符串進行切分，躲避過了簡單的特征字符串檢測，這也是很多其他EK攻擊包所常用的方法。

這種方法進一步進行混淆的話，就可以將這些字符串采用拼接、正則替換的手法，例如樣本c288ccd842e28d3845813703b9db96a4中，使用了如下的方法，基本可以完美的躲避字符串特征檢測。

圖1 字符串拆分

此外，ActionScript和JavaScript同樣基于ECMAScript，因此很多JavaScript的混淆方法同樣適用于ActionScript，例如下標運算符同樣能夠用于訪問對象的成員，這時可以參照JavaScript常見混淆方法來進行代碼還原。

在樣本eeb243bb918464dedc29a6a36a25a638中，摘錄了部分采用下標運算來訪問對象成員的代碼，如下所示：

代碼1 下標運算符執行類成員

#!javascript
vree = getDefinitionByName("flash.utils.ByteArray") as Class;
weruji = "length";
var _loc2_:* = new vree();
wxwrtu = "writeByte";
while(_loc7_ < _loc4_[weruji])
{
    _loc2[wxwrtu](_loc4_[_loc7_]);
    _loc7_++;
}

以上這段代碼等價于如下代碼段：

代碼2 還原后的代碼

#!javascript
var _loc2_:* = new flash.utils.ByteArray();
while(_loc7_ < _loc4_.length)
{
    _loc2_.writeByte(_loc4_[_loc7_]);
    _loc7_++;
}

0x02 外殼flash加密

除了字符串及調用函數名以外，還有一大塊比較重要的特征是ShellCode。ActionScript中ShellCode經常是存放在數組、Vector中，或者使用連續的pushInt、pushByte等代碼構造，這些大段連續的代碼，也是非常明顯的特征，并且大多數情況下都不會有大幅度的改變。為了加密掉這些特征，通常會采取類似PE的加密殼的方法，使用一個外層的Flash解密并加載實際的帶有漏洞利用功能的Flash文件。這樣外殼Flash的功能非常簡單，沒有明顯的特征，每次只需要對外殼Flash進行簡單的特征修改，就能夠躲避特征查殺。

隨之帶來的問題是，如何存儲這些加密的數據。最初的方法是直接存儲與大段的字符串中。例如樣本eeb243bb918464dedc29a6a36a25a638中，可以發現其存在一個非常長的字符串，如圖2中的this.ybe所示。外殼Flash正是通過對該字符串進行解碼和解密，得到實際的Flash，并進行加載。其具體的過程如下：

圖2 樣本中的長字符串

1.Base64解碼

主要是將字符串轉換成二進制數據，代碼中的wigr方法就是Base64解碼函數的具體實現。這也是非常常用的方法，如果看到類似圖2中的this.eruuf字符串，則基本可以認為使用了Base64編碼方法。

2.進行簡單的解密運算，獲得其實際的Flash。

其具體的解密是使用RC4對稱加密算法。解密代碼包含兩個256次的循環，第一個while循環將是S盒初始化，第二個while循環是根據解密密鑰打亂S盒，看到這個代碼就可以猜測是使用了RC4加密算法。解密的key則是圖2中的this.jety。

圖3 樣本解密代碼

解密出來的樣本md5是d9f01b5a3b3dd6616491f391076fbb8f，其代碼結構就與早期的未加密AnglerEK代碼結構一致。外殼Flash會使用LoadBytes函數加載這個解密出來的Flash，此處就使用了字符串替換以便掩蓋調用LoadBytes函數。

圖4 LoadBytes代碼

0x03 BinaryData存儲加密數據

方法二中的長字符串，也是一個非常明顯的特征，因此后續AnglerEK選擇這個數據存儲于BinaryData結構中，這也是當前很多的Flash加密工具的做法，例如Doswf等。

AnglerEK應該是調用了某個加密工具，把實際的Flash加密后存儲在BinaryData中，這個加密工具包有個特點是默認打開的時候存在兩個不同顏色并且在不停旋轉的字符串動畫。例如樣本56827d66a70fb755967625ef6f002ad9中，變存在這樣的動畫，其加密算法的特點是會構造一個長度為91的字符數組，BinaryData里面的數據字符都在這個范圍內，然后變換出實際的二進制數據，最后對這些數據進行解碼后zlib解壓得到數據。

AS3代碼過長，這里使用python代碼實現相同的解密過程，具體的AS3代碼，可以使用FFDec打開該文件，不過要注意的是，在反編譯這個代碼的過程中，FFDec會丟失部分代碼，可以同時使用AS3 Sorcerer配合查看。

圖5 BinaryData數據解碼代碼

隨后樣本6cb6701ba9f78e2d2dc86d0f9eee798a又對這個算法進行了一定的改進，對于解碼出來的數據，進行了異或解密，對應的Python代碼如下：

圖6 數據解密代碼

0x04 圖片存儲加密數據

實際上，不論如何加密數據都無法阻止分析人員手工分析并解密提取文件的，只能增加分析難度。例如近期的樣本c288ccd842e28d3845813703b9db96a4則不再采用將數據存放與BinaryData中，而是選擇以像素形式存儲于圖片中，以這種方式增強了躲避殺毒軟件掃描的能力。

圖7 圖片數據解密代碼

解密代碼如圖7所示，具體的過程如下：

1.提取數據

二進制數據分別存儲于非壓縮圖像的像素值中，其中，第一個像素存放實際的數據長度，剩余的像素中RGB值分別是數據的三個字節內容。把這些數據沿圖片縱向拼接在一起，便得到了所需要的內容。

2.使用RC4對獲得的數據進行解密。

請注意此處的加密算法又變成的最初的RC4，并且這種將數據存儲于圖片

的做法非常新穎，猜測這個算法應該是AnglerEK自行設計的，代碼簡單有效。

0x05 總結與展望

在本文中，解密獲得實際的Flash攻擊代碼只是分析AnglerEK所利用的Flash攻擊代碼的第一步，事實上解出的Flash攻擊代碼仍然是經過大量混淆，我們也會繼續分析這些代碼，嘗試重構其代碼結構。

除了上述手工解密Flash文件以外，另外一種比較通用方便的方法是直接Hook LoadBytes函數來解密。不論殼Flash如何解密和代碼變換，實際的Flash都會通過LoadBytes函數加載，通過Hook該函數，可以dump所有的Flash數據，但是這樣做的唯一缺點是需要把Flash運行起來。

從AnglerEK一次又一次的改變加密算法中，可以看出其躲避引擎查殺的意圖，因此采用傳統的特征掃描引擎是必然無法應對的。雖然近期AnglerEK突然停止活動，但是如此高水平的攻擊包必然會卷土重來，360QEX團隊也會繼續關注該攻擊包的后續活動，并會第一時間支持查殺。鑒于目前層出不窮的Flash漏洞攻擊，同時也建議用戶及時升級Adobe Flash Player為最新版本。

參考鏈接

技術揭秘:宏病毒代碼三大隱身術
http://bobao.#/learning/detail/2880.html

近期js敲詐者的反查殺技巧分析
http://bobao.#/learning/detail/2827.html

Is it the End of Angler ?
http://malware.dontneedcoffee.com/2016/06/is-it-end-of-angler.html