APT28

virustracker · 2015/12/25 14:53

download.bitdefender.com/resources/m…

0x00 前言

---

最初，「高級持續威脅」指的是那些使用很是規木馬，攻擊特定目標和網絡的攻擊活動。這類攻擊活動的目的是爲了長期或祕密地竊取敏感數據。在近幾年，APT開始指代由外國政府發動的長期攻擊活動，而安全公司或受害者政府會因爲害怕經濟制裁或政治壓力，不肯意指認這些攻擊者。另一點緣由是，因爲互聯網的開放特性，攻擊者能夠利用技術把罪名嫁禍給他人，從而也難以肯定他們的真實身份。

爲了肯定攻擊活動與其幕後國家之間的聯繫，Bitdefender這樣的企業但願能在APT代碼或通信基礎設施中找到切實的證據。下面的這份報告詳細地分析了APT28小組使用的有效載荷技術，經過這些信息咱們發現了他們與幕後主事之間的關聯。

0x01 目標受害者

---

近期，咱們在分析了Sofacy行動後發現，這個網絡小組至關活躍，而且有明確的地區傾向。APT28的主要目標都分佈在這幾個國家中，包括，烏克蘭，西班牙，俄羅斯，羅馬尼亞，美國和加拿大。

咱們發現，APT28對烏克蘭特別有興趣。在2015年2月10日到14日，APT28小組掃描了8,536,272個IP來尋找可能的漏洞。

巧合的是，在這期間，白俄羅斯、俄羅斯、德國、法國和烏克蘭的政治領導們正好在明斯克參加會議，討論是否中止在烏克蘭東部頓巴斯地區的交火行動。

2月14日以後，APT28小組把目標轉向了西班牙。圖1中是標出的就是受到影響的國家。

目前，咱們尚不清楚APT28會根據什麼標準來選擇目標，可是咱們研究發現，他們會從預先準備好的IP地址中挑選出有漏洞的幾個來進行攻擊。同時，咱們還發現，這些目標涉及到了各個行業：政治類、電子犯罪服務類、電信服務或航空行業。

更多受害者信息能夠在附錄1中找到。

圖1

0x02 歸屬判斷

---

咱們有理由相信，APT28的管理者是俄羅斯人，或者是會講俄語的鄰國公民。在分析中，咱們發現了不少證據都能證實咱們的猜想。

咱們第一次分析相關文件的時候，統計了在各個時區下從週一到週五天天8:00-18:00這段時間中編譯的二進制數量，結果最突出的就是UTC+4時區，有88%的文件是在這個時區下的工做時間編譯的。在這個時區下的國家中（俄羅斯，格魯吉亞，阿塞拜疆），只有俄羅斯有能力和資源來執行這種攻擊行動。

在下圖中（圖2），咱們根據編譯時間，對樣本進行了分組（UTC+4）。從圖中能夠看到，大部分樣本是在8:00-18:00編譯的。

圖2

另外一條線索是從一個用於獲取系統權限的黑客工具中找到的。這條線索也能證實咱們的假設-木馬做者來自一個說俄語的國家。咱們在查找相關的APT28文件時，發現了這個工具。文件的標頭叫作xp.exe (78450806E56B1F224D00455EFCD04CE3)，這個文件很特別的地方是，在調試文件中硬編碼了一個路徑xp.exe (78450806E56B1F224D00455EFCD04CE3)。字符串Пользователь就是爲俄羅斯的用戶準備的。

咱們有理由相信，這個文件也是APT28開發的，由於這個文件的修改/建立日期被更改成了14/04/2008, 16:00，與APT28在攻擊活動中使用的其餘文件相同。全部在攻擊中使用的文件都是在2013年後編寫的。攻擊者修改文件的日期是爲了防止受害者在系統上發現新文件，避免引發用戶的懷疑。

0x03 搜索新目標

---

咱們發現，有些服務器的主要目的就是爲了自動搜索新的受害者。這是經過大規模的掃描和刺探預先肯定好的IP地址範圍實現的。服務端應用包括4個主要組件，以下：

• 一個Python腳本（gen_ip.py），用於隨機生成符合特定類的IP地址
• 一個數據庫（shodb），用於集中全部掃描到的數據並篩選潛在受害者
• 一個Django（sho）應用，用於管理bot和報告

APT沒有采起「亂槍打鳥」的方法，而是挑選受害者。這個Python腳本中硬編碼了一些IP類；腳本會遍歷全部的子網，並隨機生成符合範圍的IP地址。若是攻擊者掃描範圍內的全部IP，這樣會增長引發用戶注意的概率。在隨機生成了IP後，這些IP就會被添加到數據庫。而後每一個IP地址會給定一個優先級等級。

截止咱們撰寫報告時，數據庫中總共包含了58,624個相關的IP，具體參考附錄1。全部這些IP的優先級都設置爲了1。

掃描bot都是相互獨立的系統，分佈在不一樣的網絡中。咱們猜想，這種方法能讓掃描過程看起來不是那麼可疑。若是是來自同一個網絡的一個或多個IP來掃描整個子網，可能會引發用戶的懷疑，或觸發入侵檢測系統。

爲了完成掃描任務，每一個bot會經過cookie來認證服務器。認證成功後，掃描bot每次請求最多能夠接收到16個IP。而後，bot會使用nmap工具（附錄1）掃描每一個IP的特定端口。若是找到了開放的端口，bot就會聯繫服務器，並把nmap獲取到的信息保存到數據庫中。接着，相應的IP地址就會被標註上「有漏洞」。圖3中描述的就是這一過程：

圖3

掃描bot的位置分佈以下：美國3個，英國3個，保加利亞3個（圖5）：

圖5

0x04 攻擊流程

---

APT28主要依賴3種不一樣的攻擊途徑來感染他們的目標：用惡意Word和Excel文檔做爲附件的釣魚郵件，釣魚網站，會致使Java和Flash 0-day漏洞的惡意iFrame。

客戶端一般是由於訪問了掛載着漏洞工具的URL，才被感染 。在成功感染後，第一階段的dropper（在咱們這裏是runrun.exe）會寫到磁盤上。這個dropper的主要目的是爲了投放一個文件(api-ms-win-downlevel-profile-l1-1-0.dll)，並使用rundll32.exe執行這個文件。這樣作是爲了聯繫CC服務器，並下載第二階段的木馬。

第二階段的組件會使用和上面相同的方法來安裝到客戶端上。首先，執行一個dropper(winloat.exe)，dropper會把一個關鍵組件(advstoreshell.dll)和一個配置文件(msd)寫到磁盤上。這個配置文件中包含有一些關鍵信息，好比後門會嘗試聯繫的三個服務器(win*********ore.net ,micro********er.com和1***.net)，請求間隔，以及是否啓動鍵盤記錄功能的旗幟。

此時，攻擊者就已經控制了受害者的機器，而且部署了不一樣的工具和組件。在咱們分析的例子中，攻擊者下載了3個攻擊工具：

1. 一個用於轉儲登陸用戶密碼的工具(run.exe)
2. 一個利用權限提高漏洞(CVE-2014-4076)獲取系統權限的工具(xp.exe)
3. 一個用做代理，即便路由器系統，也能容許攻擊者與系統取得聯繫的工具(svehost.exe)

另外還有一個組件也是經過下載獲取的(pr.dll)，這是一個模塊化組件，用於把竊取到的數據上傳到CC服務器。

圖6

攻擊流程如圖6：

在部署了有效載荷後，攻擊者會把第二階段dropper下載的文件都修改爲在14/04/2008, 16:00編寫的。經過這種技術，攻擊者能夠隱藏惡意文件，避免受害者發現磁盤上寫入了新文件從而起疑。

下表中列出了各個文件的編譯日期和建立日期。

表1

最近的建立日期是13/05/2015，多是攻擊活動開始的日期。鑑於從第一階段downloader到第二階段downloader寫入到磁盤上大約有1小時的間隔，咱們懷疑這個過程是人工操做的。在全部的文件中，只有一個不是在攻擊以前編譯完成的。「%allusersappdata%\ Pr.dll」是惟一一個在攻擊活動開始了5小時後才編寫的。由此來看，這個文件是針對目標特地製做的。

0x05 遭到攻擊的受害者

---

咱們發現，遭到攻擊的受害者屬於不一樣的行業和部門。研究代表，受害者主要是政治人物、政府機構、電信和電子犯罪服務，以及德國、烏克蘭、俄羅斯和羅馬尼亞的航空航天公司。

有些受害者是咱們經過分析中心服務器上的信息肯定的。在這些信息中，包括失竊郵件的蹤影。有一部分是咱們的內部系統上報的。

經過在中心服務器上發現的郵件，咱們肯定了前兩類受害者。

政治人物

在2015年5月13日，兩個.pst文件‘C:\ProgramData\backup.pst’和‘C:\ProgramData\backup2.pst’複製到了服務器上。

航空航天業

在2015年7月9日，14個文檔複製到了服務器上。在這之中，有兩個.dbx (Outlook Express數據庫)文件。

在7月18日，「F:\Outlook Express\AC_VTS_ÐÊÒ.dbx」傳輸到了中心服務器。

一樣是在7月18日，「F:\Outlook Express\Kydla.dbx」也傳輸到了中心服務器。

全部這些受害者彷佛都與航天業或飛行器研究項目有關聯。經過上下文，也能看出攻擊者可能來自俄羅斯，考慮到媒體也在大量報道俄羅斯的PAK FA T-50戰鬥機和美國的F-35戰鬥機。

咱們的內部系統也標記了大量遭到攻擊的計算機。在羅馬尼亞，這些標記出來的計算機有一部分屬於政府基礎設施或與羅馬尼亞政府有密切關聯。

0x06 附錄1（目標活動）

---

經過分析APT28的CC服務器，咱們發現了兩起尋找新目標的活動。

在這個過程當中，攻擊者根據從數據庫中獲取的IP地址，掃描了大量IP的端口。端口掃描過程是經過一個免費工具「nmap」實現的。若是找到了開放的端口，這個IP就會被標記爲「有漏洞的」，而且會保存相應的信息。探測命令都包括在下圖中：

圖7

其中：

• T5:在很短的時間內映射一個主機，前提是你的網絡要夠快，或者是不介意丟失部分信息。
• p:掃描特定的端口
• sV:檢測遠程服務（服務器/守護進程）的版本號
• O:識別一個遠程主機apps和
• version-light:啓動精簡模式，加速掃描過程，可是識別服務的能力會稍微下降
• script=banner: 顯示ftp banner 響應
• script=http-headers:經過一條HEAD請求web服務器的根文件夾(「/」)，並顯示返回的HTTP標頭
• oX:把掃描結果記錄成XML形式，保存到參數指定的文件
• iL:根據配置文件而不是命令行來讀取目標規範；在配置文件中會包含有主機列表和網絡表達

在2015年2月10日，咱們發現了攻擊者的首次嘗試，掃描了8.762.102的一些IP。在這之中，1.712.363 IP被標記爲了「有漏洞」。此次探測活動一直持續到了2月14日。大多數IP都是來自烏克蘭（掃描了8.536.272，1.704.837是有漏洞的）。

被掃描的IP數量很龐大，幾乎至關於烏克蘭的總IP數量。經過搜索在這段時間內發生的與烏克蘭相關的重大事件，咱們意識到，此次探測過程是在明斯克峯會期間進行的，在此次峯會上主要討論了烏克蘭歐諾個不頓巴斯地區的衝突問題。在2月11日，白俄羅斯，俄羅斯，德國，法國和烏克蘭的領導人在一塊兒協商新一輪的和平協議，這一協議於2月12日發佈，在2月15日簽署。

在下表中（表2），列出了這些活動的目標國家：

表2

在2月14日，一個數據庫備份保存到了一個文件(file.csv)中，而且攻擊者的關注焦點從烏克蘭轉向了西班牙。

在2月16日，攻擊者又開始嘗試尋找新的受害者。新的數據庫加載了58,624個新的IP地址，在這之中，有6,146個是有漏洞的。表3中列出了此次活動的目標國家：

表3

在第二次嘗試中，掃描的IP範圍很小，咱們猜想此次攻擊活動多是有具體的目標機構。經過分析目標IP範圍，咱們肯定了一些受害者。

咱們尚不清楚，攻擊者是根據什麼標準來肯定目標，可是咱們猜想攻擊目標是人工肯定對的，而不是經過自動方式完成。

0x07 附錄2-探測過程

---

目標篩選過程是經過中心CC服務器管理的多個bot完成的。行動流程能夠分爲下面的幾個過程：

1. 生成新受害者

   潛在受害者是經過掃描不一樣子網的IP端口來肯定的。這些IP列表是經過腳本gen_ip.py生成的，這個腳本會經過IP類別或隨機選擇IP來探測其端口。在寫報告時，這個腳本硬編碼了11個IP類，因此，咱們認爲受害者組織是人工選擇的。

   這個腳本會隨機生成整數數字，這些數字表明瞭屬於不一樣類的IP。事實上，這個腳本不會遍歷全部的IP，這就代表，攻擊者採起了預防措施，避免觸發受害者的入侵檢測系統-由於掃描一個子網的全部IP可能會引發受害者的懷疑。

   全部生成的IP都會添加到中心服務器上的一個數據庫中。大多數IP是屬於西班牙和一些政治機構，電信公司和公共事務機構。

2. 集中全部信息

   這個CC服務器最重要的資產是shodb數據庫。在恢復了數據庫中，咱們發現了下面的關係（圖9）：

   圖9

   sho_bot表中包含有與活動bot相關的信息（表5）

   

   表4

   這裏有9個bot，每一個bot都是經過一個cookie（uid）識別的。bot會使用這個cookie來註冊到主要服務器上。若是服務器有這個cookie的引用，過程就會繼續。全部bot的優先級（code_id）都設置爲了1。全部項目的info一欄都是空白的。

   sho_cookie表中包含有與bot活動相關的信息（表6）

   

   

   cookie欄表示的是認證代碼，last_activity欄表明是bot聯繫服務器的最後時間，ip_addr一欄表明的是bot的IP地址，get_num欄表示的是bot與中心服務器之間的鏈接數量。

   此次研究代表，有些bot是重複的，而cookie有兩類：一種使用了字母和數字，一種只是使用了數字。第一種cookie的活動很是少（每一個cookie有3個鏈接），由此咱們認爲有兩個版本的bot和插件在並行。另外，根據第一類cookie不在sho_bot表中出現，也能證實這一點。

   • sho_ip表中包含有gen_ip.py腳本生成的IP列表
   • sho_plugin表中包含的是代碼而不是數據。這裏儲存了腳本plugin-nmap-0.43.py。這個腳本的主要做用是獲取目標IP（每次請求最多16個IP）並執行掃描命令（圖10）。

   圖10

   在解析了nmap結果後，數據會發送回服務器並保存到sho_ip表中的數據庫。

   • sho_code表中包含的是代碼，而不是數據。這裏儲存着scan-bot-03.py腳本。這個腳本負責描述系統的行爲。Bot會鏈接到服務器並使用一個cookie來註冊本身。一旦經過認證，bot就會從sho_code表（更新機制）中請求最新的代碼和插件(sho_plugin)版本。在更新後，bot就會啓動一系列的線程，使用最新的插件掃描目標IP。
   • sho_log表是空的
   • sho_setting表是空的

   服務器上還運行着一個Django應用。這個應用是一個管理和報告界面，用於管理bot和目標。下圖中就是（圖11）admin面板。這個界面容許攻擊者查看統計數據，添加和刪除用戶、目標和bot。

   圖11

   這個界面很簡單，只是對數據庫簡單的包裝了一下（圖12：添加用戶【上】，添加目標【下】）：

   圖12

   1.bot

   用於掃描潛在受害者的機器也是不一樣的。這樣便於攻擊者隱藏這些IP的掃描活動是否是屬於同一次行動的。下表中是咱們在數據庫中發現的IP（表7）：

   表7

0x08 附錄3-與APT28相關的工具

---

代理工具(svehost.exe)

這個可執行文件要麼使用了經過命令行傳遞的參數，要麼就沒有使用參數。當沒有參數執行時，文件會嘗試聯繫IP地址：端口443上的176.**.***.10。

也能夠啓動下面的命令行:

#!bash
svehost.exe start <ipaddress> <port>
複製代碼

這個文件使用了一箇舊版的OpenSSL庫(OpenSSL 1.0.1e)。實際上，這個文件之因此有1038kb，就是由於包含了這個OpenSSL庫。

這個工具的主要目的是容許攻擊者聯繫路由器後的系統，若是沒有這個工具，系統就沒法從網絡外訪問。

權限提高工具(xp.exe)

這個工具是圍繞一個在2014年發現的漏洞(CVE-2014-4076)建立的，經過使用函數DeviceIoControl向\\.\\ TCP設備發送一個特殊的數據包來運行。在2014年底，這個漏洞就被修復了。

這個工具會接收一個可執行文件做爲參數。而後，使用系統權限運行這個可執行文件。

這個文件是根據調試配置編譯的。所以，文件中還硬編碼了一個pdb文件的路徑。這個路徑引用了C:\Users\Пользователь\Desktop\cve-2014-4076\cve-19abdba\Debug\CVE-2014-4076.pdb

字符串Пользователь在俄語中的意思是「用戶」。這也是咱們懷疑木馬做者是俄語用戶的緣由。

木馬轉儲工具(run.exe)

這個木馬轉儲工具彷佛是根據mimikatz來建立的，這個公共工具會經過LSASS轉儲WDigest中的密碼。更多關於這個工具的信息能夠訪問blog.gentilkiwi.com/mimikatz。

這個文件是在05/05/2013編譯的，而且不包含任何版本信息。也就是說，這個文件是做者本身編譯的。這個工具會接收一個文件做爲參數，而後，獲取到的密碼會轉儲到文件中，做爲參數傳遞。

0x09 附錄4（第一階段組件）

---

在感染後，這是第一個安裝到受害者計算機上的組件。這個組件的目的是聯繫CC服務器並要求接下來的指令。

第一階段的有效載荷包含兩個部分：一個dopper和第一階段的後門。咱們遇到的dropper-runrun.exe，在數據節內嵌了文件api-ms-win-downlevel-profile-l1-1-0.dll。dopper使用了大量的自定義加密算法來避免逆向。

下面的算法（算法1）是用於解密其API：

算法1：

有效載荷(api-ms-win-downlevel-profile-l1-1-0.dll) 使用了RTL和自定義加密算法進行了加密，使用了一個10字節祕鑰。

算法2：

投放的文件是一個downloader，這個文件會聯繫CC服務器獲取第二階段的組件。Downloader聯繫的域名是：_www.msc****vw.com_，IP地址是：91.***.**.249。

使用的請求是經過GET over HTTP。每一個請求1-5組隨機的1到6的數字。經過斜線來分組，下面就是一個請求：

#!bash
/ue/VHghm/ihXAIK/qpi/1c9.xml/?XK1=VrLYQndXGXwzURh9RBE=
複製代碼

上面的xml擴展實際是從4個可用的擴展的選擇的（xml, **pdf,html, zip**）。最後的參數是一個加密祕鑰，downloader可能會利用這個祕鑰來經過服務器認證。

這個文件是一個基礎的後門，具備下面可用的命令：

• 下載
• 執行
• 刪除文件

由於須要1個多小時第二階段的組件才能下載到受感染的系統上，因此咱們猜想是手動下載的。

0x0A 附錄5-（第二階段組件）

---

第二階段組件的目的是打開後門，容許攻擊者訪問目標設備，並下載另外的組件。

a. Dropper:

做爲的第一階段組件，重要文件都是使用dropper安裝的。(winloat.exe)

Dropper的主要操做包括：

• 解密（包括後門：advstoreshell.dll和配置文件：msd）
• 將有效載荷寫入磁盤上
• 調用advstoreshell.dll的InitW方法

b. 配置文件：

爲了加密/解密配置文件和advstoreshell.dll使用的API，攻擊者使用了一個6字節長度的自定義流密碼。下面的函數是爲了獲取相應的字節，用於異或緩衝區中的一個索引。

算法3：

配置文件(msd)就是使用了上面介紹的算法，使用了122字節的祕鑰。配置文件中包含有下列信息：

其中：

• Timeout1 = 60000 ; 表明在聯繫CC時，直到超時的毫秒數
• Timeout2 = 60000 ; 表明在使用加密聯繫CC時，直到超時的毫秒數
• Computer name = DAE13WS01204030501 ; 受感染計算機的名稱
• DomainName1= micro**********ter.info
• DomainName2=dri********te.info
• Campaign id = rhbp ; 咱們還在調查這個字段的含義，可是，這多是一個活動標識符
• ? = 1000 ; 咱們仍然在調查這個字段的角色，可是一些信息讓咱們認爲這是一個計數器
• ? = 600000; 咱們仍然在調查這個字段的含義，可是極可能是另外一個超時值
• Keylogging flag = 1; 這個字段指示着後門是否應該攔截鍵盤輸入，並將輸入發送到CC服務器
• Main domain name = 1***.net ; 這是木馬嘗試聯繫的第一個域名

c. 後門組件：

APT28最重要的組件是後門，在咱們的例子中，這個文件叫作advstoreshell.dll。這個文件會讀取配置文件(msd)，並聯系配置文件中的CC服務器。而且配置文件也能夠儲存到註冊表中。在註冊表中儲存的配置文件多是從某個CC服務器上的更新獲取的。

在咱們分析過的系統上，有2個配置文件：

1. 第一個是msd文件，與advstoreshell.dll在相同的路徑下
2. 第二個在註冊表中(HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Path)。這個文件中的數據與msd文件基本相同，除了前兩個域名更改成了…ore.net和micr…er.com。

只有這個組件會在啓動時運行。這是經過在HKCU\ Software\Microsoft\Windows\CurrentVersion\Run中建立AdvancedStorageShell實現的，寫入的內容是：

#!bash
"RUNDLL32.EXE "C:\Documents and Settings\<user-name>\Local Settings\Application Data\Microsoft Help\advstorshell.dll", InitW"
複製代碼

這個後門很先進，支持26種命令。咱們分析了一些命令，其餘的一些命令仍在分析過程當中。

在使用cmd/c選項運行命令時，輸出會保存到一個叫作tmp.dat的文件中。

這個組件與CC服務器之間的通信是經過HTTP端口443實現的。若是可行，這個組件會嘗試鏈接端口80。在有些狀況下，通信會使用3DES和RSA加密。

這個後門的一個重要功能就是能加載外部組件。這是經過調用dll的init函數實現的。s插件也是這樣加載的。

0x0B 附錄6-額外模塊

---

APT28最後安裝的組件是一個叫作pr.dll的模塊。這個文件是在系統遭到入侵的5小時後編譯的。這種時間上的誤差讓咱們懷疑這個文件是根據每一個目標系統單獨製做的。

這個文件彷佛是一個模塊化框架，能兼容不一樣的模塊。這個文件的配置儲存在一個加密格式中，並保存在註冊表鍵值中「HKU\S-1-5-19_Classes\Software\Microsoft\MediaPlayer\{some_clsid}\chnnl」

一旦執行，木馬會檢查一個互斥量(XSQWERSystemCriticalSection_for_1232321)是否是存在，從而確保只有一個實例在運行。而後，木馬會聯繫服務器（IP: 198.[redacted].74，或域名sec[…]win. com）。在初始通信階段，後門會向CC服務器發送一個加密的buffer，包含有一個RC4祕鑰和插件的ID。下面就是一個buffer：

03 33 02 03 33 23 03 21 23 06 21 23 3A 66 95 64 4B 56 FF 22 4D 81 4F

咱們使用下列在buffer中的ID識別出插件：0x3302, 0x3303, 0x2103, 0x2106\

頗有趣的是，pr.dll會建立兩個管道，多是用於收集其餘進程發送的數據。

pr.dll彷佛是在服務器上發現的一個Windows版Linux文件。在服務器上有4個elf文件，有兩個是x86架構(075b6695ab63f36af65f7ffd45cccd39, f3bf929a35c3f198226b88537d9ccb1a)，兩個是x64架構(2683624eacc490238e98c449bddbb573, 5bf524a4860f3c33e3ad77b6b625db37)。這個elf文件使用了SQLite3來儲存其配置，而不是註冊表。My_BD數據庫包含有兩個變量chnnl和prms。

這些文件會經過構建隨機請求，嘗試聯繫服務器。每一個請求都有一個動做watch/,search/,results/,search/,close) 和2-9個變量（選擇：text=,from=,itwm=,ags=,oe=,aq=,btnG=,oprnd=,utm=,channel=）。參數值是隨機生成的。

下面是一個請求：

h[tt]p://198.***.***.74/watch/?aq=JTfJRp-s&oprnd=Dwtee&itwm=niKMuGE9Mp9Md9vHdggZMS16YlSTx&btnG=t&oprnd=FbLtw&AVVAT=m 8I2tN

elf文件中包含有下列模塊：

1. AgentModule
2. KernelProvider
3. AgentKernel
4. ChannelController
5. Cryptor
6. LocalStorage (sqlite3) 7. ReserverApi
7. AgentChannel
8. HttpChannel
9. FSModule
10. RemoteShell
11. RemoteKeylogger

如上所述，每一個架構都有兩個版本。惟一區別就是有一個版本中不會包含最後的兩個模塊。