最初,“高級持續威脅”指的是那些使用非常規木馬,攻擊特定目標和網絡的攻擊活動。這類攻擊活動的目的是為了長期或秘密地竊取敏感數據。在近幾年,APT開始指代由外國政府發動的長期攻擊活動,而安全公司或受害者政府會由于懼怕經濟制裁或政治壓力,不愿意指認這些攻擊者。另外一點原因是,由于互聯網的開放特性,攻擊者可以利用技術把罪名嫁禍給他人,從而也難以確定他們的真實身份。
為了確定攻擊活動與其幕后國家之間的聯系,Bitdefender這樣的企業希望能在APT代碼或通訊基礎設施中找到切實的證據。下面的這份報告詳細地分析了APT28小組使用的有效載荷技術,通過這些信息我們發現了他們與幕后主事之間的關聯。
近期,我們在分析了Sofacy行動后發現,這個網絡小組相當活躍,并且有明確的地區傾向。APT28的主要目標都分布在這幾個國家中,包括,烏克蘭,西班牙,俄羅斯,羅馬尼亞,美國和加拿大。
我們發現,APT28對烏克蘭特別有興趣。在2015年2月10日到14日,APT28小組掃描了8,536,272個IP來尋找可能的漏洞。
巧合的是,在這期間,白俄羅斯、俄羅斯、德國、法國和烏克蘭的政治領導們正好在明斯克參加會議,討論是否停止在烏克蘭東部頓巴斯地區的交火行動。
2月14日之后,APT28小組把目標轉向了西班牙。圖1中是標出的就是受到影響的國家。
目前,我們尚不清楚APT28會根據什么標準來選擇目標,但是我們研究發現,他們會從預先準備好的IP地址中挑選出有漏洞的幾個來進行攻擊。同時,我們還發現,這些目標涉及到了各個行業:政治類、電子犯罪服務類、電信服務或航空行業。
更多受害者信息可以在附錄1中找到。
圖1
我們有理由相信,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年后編寫的。攻擊者修改文件的日期是為了防止受害者在系統上發現新文件,避免引起用戶的懷疑。
我們發現,有些服務器的主要目的就是為了自動搜索新的受害者。這是通過大規模的掃描和刺探預先確定好的IP地址范圍實現的。服務端應用包括4個主要組件,如下:
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
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個攻擊工具:
另外還有一個組件也是通過下載獲取的(pr.dll),這是一個模塊化組件,用于把竊取到的數據上傳到CC服務器。
圖6
攻擊流程如圖6:
在部署了有效載荷后,攻擊者會把第二階段dropper下載的文件都修改成在14/04/2008, 16:00編寫的。通過這種技術,攻擊者可以隱藏惡意文件,避免受害者發現磁盤上寫入了新文件從而起疑。
下表中列出了各個文件的編譯日期和創建日期。
表1
最近的創建日期是13/05/2015,可能是攻擊活動開始的日期。鑒于從第一階段downloader到第二階段downloader寫入到磁盤上大約有1小時的間隔,我們懷疑這個過程是人工操作的。在所有的文件中,只有一個不是在攻擊之前編譯完成的。“%allusersappdata%\ Pr.dll”是唯一一個在攻擊活動開始了5小時后才編寫的。由此來看,這個文件是針對目標特意制作的。
我們發現,遭到攻擊的受害者屬于不同的行業和部門。研究表明,受害者主要是政治人物、政府機構、電信和電子犯罪服務,以及德國、烏克蘭、俄羅斯和羅馬尼亞的航空航天公司。
有些受害者是我們通過分析中心服務器上的信息確定的。在這些信息中,包括失竊郵件的蹤跡。有一部分是我們的內部系統上報的。
通過在中心服務器上發現的郵件,我們確定了前兩類受害者。
政治人物
在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_Dêò.dbx”
傳輸到了中心服務器。
同樣是在7月18日,“F:\Outlook Express\Kydla.dbx”
也傳輸到了中心服務器。
所有這些受害者似乎都與航天業或飛行器研究項目有關聯。通過上下文,也能看出攻擊者可能來自俄羅斯,考慮到媒體也在大量報道俄羅斯的PAK FA T-50戰斗機和美國的F-35戰斗機。
我們的內部系統也標記了大量遭到攻擊的計算機。在羅馬尼亞,這些標記出來的計算機有一部分屬于政府基礎設施或與羅馬尼亞政府有密切關聯。
通過分析APT28的CC服務器,我們發現了兩起尋找新目標的活動。
在這個過程中,攻擊者根據從數據庫中獲取的IP地址,掃描了大量IP的端口。端口掃描過程是通過一個免費工具“nmap”實現的。如果找到了開放的端口,這個IP就會被標記為“有漏洞的”,并且會保存相應的信息。探測命令都包括在下圖中:
圖7
其中:
在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范圍,我們確定了一些受害者。
我們尚不清楚,攻擊者是根據什么標準來確定目標,但是我們猜測攻擊目標是人工確定對的,而不是通過自動方式完成。
目標篩選過程是通過中心CC服務器管理的多個bot完成的。行動流程可以分為下面的幾個過程:
生成新受害者
潛在受害者是通過掃描不同子網的IP端口來確定的。這些IP列表是通過腳本gen_ip.py生成的,這個腳本會通過IP類別或隨機選擇IP來探測其端口。在寫報告時,這個腳本硬編碼了11個IP類,所以,我們認為受害者組織是人工選擇的。
這個腳本會隨機生成整數數字,這些數字代表了屬于不同類的IP。事實上,這個腳本不會遍歷所有的IP,這就表明,攻擊者采取了預防措施,避免觸發受害者的入侵檢測系統-因為掃描一個子網的所有IP可能會引起受害者的懷疑。
所有生成的IP都會添加到中心服務器上的一個數據庫中。大多數IP是屬于西班牙和一些政治機構,電信公司和公共事務機構。
集中所有信息
這個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表中出現,也能證明這一點。
gen_ip.py
腳本生成的IP列表plugin-nmap-0.43.py
。這個腳本的主要作用是獲取目標IP(每次請求最多16個IP)并執行掃描命令(圖10)。 圖10
在解析了nmap結果后,數據會發送回服務器并保存到sho_ip表中的數據庫。
scan-bot-03.py
腳本。這個腳本負責描述系統的行為。Bot會連接到服務器并使用一個cookie來注冊自己。一旦通過認證,bot就會從sho_code表(更新機制)中請求最新的代碼和插件(sho_plugin)版本。在更新后,bot就會啟動一系列的線程,使用最新的插件掃描目標IP。服務器上還運行著一個Django應用。這個應用是一個管理和報告界面,用于管理bot和目標。下圖中就是(圖11)admin面板。這個界面允許攻擊者查看統計數據,添加和刪除用戶、目標和bot。
圖11
這個界面很簡單,只是對數據庫簡單的包裝了一下(圖12:添加用戶【上】,添加目標【下】):
圖12
1.bot
用于掃描潛在受害者的機器也是不同的。這樣便于攻擊者隱藏這些IP的掃描活動是不是屬于同一次行動的。下表中是我們在數據庫中發現的IP(表7):
表7
代理工具(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中的密碼。更多關于這個工具的信息可以訪問http://blog.gentilkiwi.com/mimikatz。
這個文件是在05/05/2013編譯的,并且不包含任何版本信息。也就是說,這個文件是作者自己編譯的。這個工具會接收一個文件作為參數,然后,獲取到的密碼會轉儲到文件中,作為參數傳遞。
在感染后,這是第一個安裝到受害者計算機上的組件。這個組件的目的是聯系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個多小時第二階段的組件才能下載到受感染的系統上,所以我們猜測是手動下載的。
第二階段組件的目的是打開后門,允許攻擊者訪問目標設備,并下載另外的組件。
a. Dropper:?
作為的第一階段組件,重要文件都是使用dropper安裝的。(winloat.exe)
Dropper的主要操作包括:
b. 配置文件:
為了加密/解密配置文件和advstoreshell.dll使用的API,攻擊者使用了一個6字節長度的自定義流密碼。下面的函數是為了獲取相應的字節,用于異或緩沖區中的一個索引。
算法3:
配置文件(msd)就是使用了上面介紹的算法,使用了122字節的秘鑰。配置文件中包含有下列信息:
其中:
micro**********ter.info
dri********te.info
1***.net
; 這是木馬嘗試聯系的第一個域名c. 后門組件:
APT28最重要的組件是后門,在我們的例子中,這個文件叫做advstoreshell.dll。這個文件會讀取配置文件(msd),并聯系配置文件中的CC服務器。并且配置文件也可以儲存到注冊表中。在注冊表中儲存的配置文件可能是從某個CC服務器上的更新獲取的。
在我們分析過的系統上,有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插件也是這樣加載的。
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文件中包含有下列模塊:
如上所述,每個架構都有兩個版本。唯一區別就是有一個版本中不會包含最后的兩個模塊。