譯者:知道創宇404實驗室翻譯組
原文鏈接:https://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/

ESET公司研究發現了一個以前未記錄的 UEFI bootkit,其根源可以追溯到至少2012年

前言

ESET 的研究人員發現了一個以前從未記錄的真實存在的 UEFI bootkit,它現在仍然存在于 EFI系統分區上,我們稱之為 ESPecter 。它可以繞過驅動程序強制簽名限制來加載自己的未簽名驅動程序,這為其間諜活動提供了便利。除了卡巴斯基最近發現的關聯不大的 FinSpy bootkit,現在可以肯定地說,現實世界中的 UEFI 威脅不再局限于Lojax使用的 SPI 閃存植入。 傳統 BIOS 基礎上的 UEFI (可擴展固件接口)已經一去不復返了。作為嵌入到現代計算機和設備芯片中的一種先進技術,它在保證操作系統前期環境安全和加載操作系統方面起著至關重要的作用。如此廣泛使用的技術成為威脅行為者尋求一勞永逸的誘人目標,這一點毫不奇怪。

概述

在過去幾年中,我們已經看過 UEFI bootkits (DreamBoot、 EfiGuard)、泄露文檔(DerStarke、 QuarkMatter)甚至泄露源代碼(Hacking Team Vector EDK)的實例,這表明真正的 UEFI 惡意軟件是存在的,不論是以SPI 閃存植入還是 ESP 植入的形式。盡管如此,到目前為止,只發現了三個 UEFI 惡意軟件(LoJaxMosaicRegressor、FinSpy)。雖然前兩個屬于 SPI 閃存植入類別,最后一個屬于 ESP 植入類別,令人驚訝的是,它不是唯一的ESP 植入類別。 現在,我們描述的最近發現的 ESPecter,是第二個使用ESP形式的UEFI bootkit,它以修補的Windows引導管理器的形式存在,進行分析。ESPecter 是在一臺遭到感染的機器上發現的,而且它配有一個具有鍵盤記錄和文檔竊取功能的用戶模式客戶端組件,因此我們認為 ESPecter 主要用于間諜活動。有趣的是,我們追溯這種威脅的根源至少可以追溯到2012年,之前它是作為一個引導工具包為傳統BIOS系統提供服務的。盡管 ESPecter 存在了很長時間,但是它的操作和升級到 UEFI的行為卻直到現在才被記錄下來。請注意,ESPecter 和卡巴斯基 FinSpy 之間唯一的相似之處在于,它們共享 UEFI 啟動管理器妥協方法。

圖1. Windows系統上的傳統引導流程(左)和 UEFI 引導流程(右)的比較
通過修補 Windows Boot Manager,攻擊者可以在操作系統完全加載之前執行系統引導過程的早期階段(參見上圖) 。因而ESPecter 可以繞過 Windows 驅動程序簽名強制(DSE) ,以便在系統啟動時執行自己的無簽名驅動程序。然后,該驅動程序將其他用戶模式組件注入到特定的系統進程中,以啟動與 ESPecter 的 c & c 服務器的通信,并允許攻擊者通過下載和運行其他惡意軟件或執行 c & c 命令來控制受到攻擊的機器。 盡管 Secure Boot 可以阻止執行ESP來源的不可信的 UEFI 二進制文件,但在過去幾年中,我們已經見證了各種 UEFI 固件漏洞,成千上萬個設備因為允許禁用或繞過 Secure Boot,而受到攻擊(例如 VU # 758382,VU # 976132,VU # 631788,...)。這表明,確保 UEFI 固件安全這個工作頗具挑戰性,而且各種供應商運用安全策略和使用 UEFI 服務的方式并不總是恰當的。 以前,我們報道過多個惡意 EFI 案例,它們是簡單的、單用途的 UEFI 應用程序,沒有廣泛的功能。這些報道以及同時發現的 ESPecter 和 FinFisher bootkit (兩者都是全功能 UEFI bootkit)表明,威脅行為者在操作系統之前的持久性方面不僅僅依賴 UEFI 固件植入,而且還試圖利用遭到禁用的 Secure Boot 來執行他們自己的 ESP 植入。 我們尚未確定 ESPecter 背后的威脅行為者。

ESPecter bootkit 的進化

當我們查看遙測數據時,我們可以將這個 bootkit 的起源追溯到至少2012年。一開始,它使用 MBR (主引導記錄)修改作為其長期使用方法,并且它的作者對新的 Windows OS 版本投入越來越多的關注。有趣的是,這些年來,這個惡意軟件的組件幾乎沒有變化,2012年和2020年版本之間的差異并沒那么明顯。 多年之后,ESPecter 背后的人顯然決定將他們的惡意軟件從傳統 BIOS 系統移植到現代的 UEFI 系統。為了實現這一點,他們修改了位于 ESP 上的合法的 Windows Boot Manager 二進制文件(bootmgfw.efi),同時覆蓋從 Windows 7到 Windows 10的多個 Windows 版本。正如我們前面提到的,這個方法有一個缺點——它要求禁用Secure Boot,以便使用修改過的boot管理器。然而,值得一提的是,第一個支持安全啟動的 Windows 版本是 Windows 8,這意味著所有以前的版本都容易受到這種方法的攻擊。 對于支持安全啟動的 Windows 操作系統版本,攻擊者需要禁用它。現在,我們還不知道 ESPecter 運營者是如何做到這一點的,但有幾種可能的情況: - 攻擊者可以對設備進行物理訪問(歷史上稱為“evil maid”攻擊) ,并在 BIOS 設置菜單中手動禁用安全啟動(固件配置菜單仍然被標記并稱為“ BIOS 設置菜單”是很常見的,甚至在 UEFI 系統中也是如此) - 安全引導已經在被攻破的機器上禁用了(例如,用戶可能會使用雙引導窗口和其他不支持安全引導的操作系統) - 利用允許禁用安全啟動的未知 UEFI 固件漏洞 - 在已過時的固件版本或不再支持的產品上利用已知的 UEFI 固件漏洞

技術分析

在我們的調查中,我們發現了一些與 ESPecter 相關的惡意組件: - 安裝程序,僅適用于bootkit的舊版 MBR 版本,其目的是通過重寫引導設備的 MBR 在計算機上設置持久性 - 啟動代碼,以UEFI系統上修改的Windows引導管理器(bootmgfw.efi)形式,或以舊引導系統中惡意MBR形式 - 內核模式驅動程序,用于為用戶模式有效負載準備環境,并在操作系統啟動的早期階段將它們注入特定的系統進程來加載 - 用戶模式有效負載,負責與 c & c 進行通信、更新 c & c 配置并執行 c & c 命令

有關 ESPecter bootkit 危害的完整方案,請參見下圖。

實現持久性-UEFI 啟動

在使用 UEFI 啟動模式的系統上,ESPecter 持久性是通過修改 Windows啟動管理器bootmgfw.efi和 回退引導裝載程序二進制 bootx64.efi 建立的,這兩個文件通常分別位于 ESP 目錄 EFI\Microsoft\Boot\和 EFI\Boot\ 中。引導加載程序的修改包括添加一個名為.efi 到 PE,并更改可執行文件的入口點地址,這樣程序流就跳轉到添加部分的開頭,如下圖所示。

原版(頂部)和修改版(底部) Windows 啟動管理器(bootmgfw.efi)的比較

簡化的啟動鏈

如下圖左側的方案所示,UEFI 系統上的引導過程(忽略固件部分)是從執行位于 ESP 中的引導加載程序開始。對于 Windows 操作系統,這部分由 Windows Boot Manager 二進制文件(bootmgfw.efi) 完成,其用途是查找已安裝的操作系統并將執行轉移到其 OS 核心引導程序-winload.efi。與引導管理器類似,OS 內核加載程序負責加載和執行引導鏈中的下一個組件—— Windows 內核(ntoskrnl.exe)。

典型的 Windows UEFI 引導流程(左)與 ESPecter 修改的引導流程(右)相比較

ESpecter 如何修改 UEFI 啟動過程

為了成功地刪除其惡意負載,ESPecter 需要在啟動過程中繞過 Windows Boot Manager 和 Windows 內核執行的完整性檢查。為了做到這一點,它尋找字節模式來識別內存中所需的函數,并相應地對它們進行補丁。 關于引導加載程序Windows Boot Manager (bootmgfw.efi),啟動工具包從修補 BmFwVerifySelfIntegrity 函數開始。此函數負責驗證引導管理器自己的數字簽名,并用于防止執行修改后的引導管理器。在下圖中,您可以看到 ESPecter 是如何使用各種字節模式搜索內存中的 BmFwVerifySelfIntegrity函數 (以支持眾多 bootmgfw.efi 版本) ,并修改這個函數,使其始終返回零,暗示函數驗證是成功的。

hex-ray 反編譯代碼——搜索和修補 BmFwVerifySelfIntegrity 函數
如前所述,這個引導裝載程序的主要目標是找到一個已安裝的操作系統并將執行轉移到其 OS 內核裝載程序。對于 Windows Boot Manager,這發生在 Archpx64TransferTo64BitApplicationAsm 函數中; 因此,ESPecter 查找這個函數是為了捕捉操作系統加載程序已加載到內存中但尚未執行的時刻。如果捕捉到這個時刻,ESPecter 補丁此函數插入自己的迂回函數,由此可以方便地在恰當時間修改內存中加載的 OS 加載程序。 操作系統加載程序的修改不包括任何完整性檢查或其他功能的補丁。在這個階段,bootkit需要重新分配它的代碼,因為作為一個 UEFI 應用程序,它在從其入口點函數返回后可能會被從內存中卸載。為此,它會使用 BlImgAllocateImageBuffer 或 BlMmAllocateVirtualPages 函數(取決于找到的模式)。在這次重新分配之后,bootkit將在負責傳輸執行到操作系統內核的函數——OslArchTransferToKernel 中插入一個迂回函數(位于先前分配的緩沖區),這樣它就可以在內存中修補 Windows 內核,時間只要在被加載后,但是被執行之前即可。Bootkit 的引導代碼的最后一個階段負責通過修補 SepInitializeCodeIntegrity 內核函數來禁用 DSE。

hex 射線反編譯 SepInitializeCodeIntegrity 函數在內存中修補前(左)和后(右)的比較

有趣的是,引導代碼還對 MiComputeDriverProtection 內核函數進行了補丁。盡管這個功能不會直接影響惡意驅動程序的成功加載,但是如果沒有在內核內存中找到并修補這個功能,bootkit 就不會繼續放置驅動程序。我們無法確定第二個補丁的用途,但是我們假設這個修改后的函數可能被其他未知的ESPecter組件使用。 - \SystemRoot\System32\null.sys(驅動器) - \SystemRoot\Temp\syslog (加密配置)

該配置由內核驅動程序部署的 WinSys.dll 用戶模式組件使用,由一個單字節的 XOR 密鑰和加密的配置數據組成。為了解密配置,WinSys.dll: - Base64對配置數據進行解碼 - XORs 使用 XOR 鍵對數據進行處理 - Base64對由“ |”分隔的每個值分別進行解碼

下圖展示了一個由于 EFI 版本的 ESPecter 放置的配置示例。IoCs 部分提供了一個完整的 IP 地址和域名列表,這些列表來自我們發現的 ESPecter bootkit 示例(包括 Legacy Boot 和 UEFI 版本)中嵌入的配置。

ESPecter bootkit EFI 版本提供的配置的解密

實現持久性-Legacy Boot

如前所述,我們現在知道的有支持 UEFI 的 ESPecter 版本,以及支持傳統啟動模式的其他版本。對于 傳統啟動模式,持久性是通過修改位于磁盤驅動器的第一個物理扇區中的 MBR 代碼這一技術實現的,這個技術較為常見,因此,我們在這里不詳細解釋它,只是對它進行總結。

ESPecter 如何修改遺留引導過程?

惡意 MBR 首先通過安裝程序解密先前復制到磁盤扇區2、3和4的代碼,鉤住實模式 INT13h (BIOS 扇區讀寫服務) 中斷處理器,然后將執行程序傳遞給原始的 MBR 代碼,并由安裝程序備份到第二扇區(扇區1)。與其他已知的 MBR 引導工具包類似,當調用 INT13h 中斷處理器 時,鉤子代碼(位于扇區0)檢查服務0x02(從驅動器讀取扇區)和0x42(從驅動器讀取擴展扇區) ,以攔截bootmgr(Windows 啟動管理器的傳統版本)的加載。注意,ESPecter 的遺留版本不需要在 bootmgr 中為 BmFwVerifySelfIntegrity 函數打補丁,因為 bootmgr 二進制文件沒有以任何方式修改。 從這一點來看,引導代碼的功能幾乎與 UEFI 版本的引導代碼相同,導致惡意驅動程序(位于第0軌道上,從第6扇區開始)被投放到下列位置之一,具體取決于架構: - \SystemRoot\System32\drivers\beep.sys?(x86) - \SystemRoot\System32\drivers\null.sys?(x64)

在這種情況下,加密的配置不會放入到syslog文件中,而是一直隱藏在損壞的磁盤的扇區5中。

傳統版本 ESPecter 使用的修改過的磁盤方案

內核模式驅動程序

驅動程序的主要目的是加載用戶模式的有效負載,設置鍵盤記錄程序,并最終刪除自身。設置鍵盤記錄程序分為兩個步驟: - 首先,它創建了一個名為\device\WebBK的設備,該設備公開了一個處理來自用戶模式組件的IRP_MJ_device_control請求的函數。?這個函數支持一個 IOCTL (輸入/輸出控制)代碼(0x22C004) ,可用于觸發負責一個異步過程調用例程的注冊,它用于處理截獲的擊鍵記錄。 - 通過為鍵盤驅動程序object\Device\KeyboardClass0IRP_MJ_讀取請求設置CompletionRoute,可以攔截擊鍵。

該過程完成后,任何進程都可以通過定義自己的例程并使用自定義 IOCTL 0x22C004來記錄截獲的擊鍵,并將其傳遞給創建的設備對象。

默認情況下,驅動程序會加載兩個基本有效負載——WinSys.dllClient.dll——它們具有下載和執行其他有效負載的能力。第一個, WinSys.DLL,它是以加密的形式嵌入到驅動程序的二進制文件中的。第二個,Client.dll,由 WinSys.dll下載到文件\SystemRoot \Temp\memlog,也是以加密的形式,使用相同的加密方法——一個簡單的帶減法的單字節異或——但不是相同的密鑰。這兩個庫都被解密并由驅動程序放到系統目錄 \SystemRoot\System32\中。

通過將WinSys.dllClient.dll庫分別注入svchost.exewinlogon.exe,可以實現它們的執行。為此,驅動程序使用 PsSetLoadImageNotifyRoutine注冊圖像加載回調例程 NotifyRoutine,用于執行: - 在winlogon.exe進程的上下文中,從Client.dll導出主線程 - 在svchost.exe進程的上下文中,從WinSys.dll導出主線程

NotifyRoutine在執行之前在內存中掛鉤winlogon.exesvchost.exe進程映像的入口點; 然后這個掛鉤負責加載和執行適當的有效負載 DLL。如下圖所示,該例程只處理正在加載的第一個svchost.exewinlogon.exe映像。

用戶模式組件–WinSys.dll

WinSys.dll充當基本更新代理,定期聯系其C&C服務器以下載或執行其他有效負載或執行簡單命令。C&C地址以及其他值(如活動ID、bootkit版本、C&C通信嘗試之間的時間和活動小時數范圍)位于配置中,可從以下位置加載: - HKLM\SYSTEM\CurrentControlSet\Control注冊表中的DefaultConfig值 - \SystemRoot\Temp\syslog文件 - 或者直接從特定磁盤扇區(傳統引導版本中)獲取

如果同時存在注冊表和磁盤存儲配置,則使用注冊表中的配置。

C&C通信

WinSys.dll使用HTTPS與其C&C進行通信,通過使用以下URL格式發送HTTP GET請求來啟動通信: https:///Heart.aspx?ti=&tn=&tg=&tv=

其中,drive_ID是主系統卷序列號的MD5散列,其他參數是識別該惡意軟件實例的具體信息。

因此,C&C可以使用顯示為字符串的命令ID(隨意后跟命令參數)進行響應。命令的完整列表見表1。

表1. WinSys 組件 c & c 命令

命令 ID 描述 網址
1或4 Exit. -
2 使用 HTTP POST 將各種系統信息(CPU 名稱、 OS 版本、內存大小、以太網 MAC 地址、已安裝軟件列表等)上傳到預定義的 URL https:///GetSysteminfo.aspx
3 下載或下載并執行文件到預定義的位置從預定義的 URL 使用 HTTP GET https:///UpLoad.aspx?ti=
5 重啟電腦?(只適用于 windowsvista) 不適用
6 使用HTTP GET從預定義的 URL 下載新配置,并將其保存到注冊表中 https:///ModifyIpaddr.aspx?ti=

用戶模式組件-Client.dll

惡意驅動程序部署的第二個有效負載是 Client.dll。它是一個后門,支持眾多的命令集(表2) ,并包含各種自動數據外泄功能,包括文檔竊取、鍵盤記錄和通過定期截屏來監視受害者的屏幕。所有收集到的數據都存儲在一個隱藏的目錄中,每個數據源都有單獨的子目錄(所用目錄路徑的完整列表可以從我們的 GitHub存儲庫中獲得)。還要注意的是,擊鍵的攔截是由驅動程序處理的,客戶機只需要將 IOCTL 0x22C004發送到驅動程序的設備,以便將截獲的擊鍵保存到文件中,從而注冊其日志功能。

客戶端負載通過將 IOCTL 發送到 bootkit 的設備驅動程序來設置鍵盤記錄器功能

客戶端組件的配置應該以加密形式存在文件覆蓋中。它包含諸多信息,如 c & c 地址和端口,表明應該收集哪些數據的標志(按鍵、屏幕截圖、具有特定擴展名的文件) ,屏幕截圖線程的時間段,外泄數據的最大文件大小,以及文件擴展名列表。

C&C 通信

客戶端設置了自身與 C&C 的通信通道。為了與 C&C 進行通信,它使用單字節 XOR 加密的 TCP 協議,與密鑰不同,該協議應用于的非空消息字節,在這里分析的活動中,密鑰是0x66。通信是通過向配置中指定的 IP: PORT 對發送信標消息來啟動的。此消息包含drive_ID值(主系統卷的序列號 MD5散列)以及一個指定消息類型的值,即命令請求或上傳收集的數據。

在執行 C&C 命令后,結果將報告給 C&C,并指定執行操作的結果代碼、命令 ID,有趣的是,每個這樣的結果報告消息都帶有一個水印/標記,表示位于偏移量0x04的寬字符串WBKP,這使得在網絡級別識別這種惡意通信更加容易。 表2. 客戶端 C&C 命令列表

命令 ID 描述
0x0000 停止后門
0x0064 執行從 C&C 接收的命令行并使用管道捕獲輸出
0x00C8 根據 C&C 命令參數的值,執行電源命令下線、斷電、重新啟動或關機
0x012C 截取前景窗口的屏幕快照,完整的屏幕快照,或者根據參數值改變自動的屏幕快照參數
0x0190 執行各種文件系統操作
0x01F4 上傳收集的數據和文件
0x0258 執行各種與服務相關的命令
0x02BC 執行各種與進程相關的命令
0x0320 修改配置值
0x0384 停止/啟動鍵盤記錄器,具體取決于參數的值

總結

ESPecter可以說明,在前OS持久性方面,威脅行為者不僅依賴 UEFI 固件植入,他們還投入時間創建了惡意軟件,但由于有 UEFI Secure Boot 等現有安全機制的存在,如果啟用和配置正確,這些惡意軟件很容易被這些機制阻止。

IoCs

一個完整的 IoCs 和示例列表可以在我們的 GitHub 存儲庫中找到。

ESET 檢測

EFI/Rootkit.ESPecter Win32/Rootkit.ESPecter Win64/Rootkit.ESPecter

C&C IP 地址和域的配置

196.1.2[.]111
103.212.69[.]175
183.90.187[.]65
61.178.79[.]69
swj02.gicp[.]net
server.microsoftassistant[.]com
yspark.justdied[.]com
crystalnba[.]com

Legacy版本安裝程序

ABC03A234233C63330C744FDA784385273AF395B
DCD42B04705B784AD62BB36E17305B6E6414F033
656C263FA004BB3E6F3EE6EF6767D101869C7F7C
A8B4FE8A421C86EAE060BB8BF525EF1E1FC133B2
3AC6F9458A4A1A16390379621FDD230C656FC444
9F6DF0A011748160B0C18FB2B44EBE9FA9D517E9
2C22AE243FDC08B84B38D9580900A9A9E3823ACF
08077D940F2B385FBD287D84EDB58493136C8391
1D75BFB18FFC0B820CB36ACF8707343FA6679863
37E49DBCEB1354D508319548A7EFBD149BFA0E8D
7F501AEB51CE3232A979CCF0E11278346F746D1F

受損的windows啟動管理器

27AD0A8A88EAB01E2B48BA19D2AAABF360ECE5B8
8AB33E432C8BEE54AE759DFB5346D21387F26902

MITRE ATT&CK 技術

下表是使用 MITRE ATT&CK 框架的第9版構建的。

策略 ID 名稱 技術
Execution T1106 ative API ESPecter leverages several Windows APIs: VirtualAlloc , WriteProcessMemory, and CreateRemoteThread for process injection.
Persistence T1542.003 Pre-OS Boot: Bootkit ESPecter achieves persistence by compromising Windows Boot Manager (bootmgfw.efi) located on the ESP, or by modifying the MBR on Legacy Boot systems.
T1547 Boot or Logon Autostart Execution ESPecter replaces the legitimate null.sys or beep.sys driver with its own malicious one in order to be executed on system startup.
Defense Evasion T1055.001 Process Injection: Dynamic-link Library Injection ESPecter’s driver injects its main user-mode components into svchost.exe and winlogon.exe processes.
T1564.001 Hide Artifacts: Hidden Files and Directories ESPecter’s Client.dll component creates hidden directories to store collected data.
T1564.005 Hide Artifacts: Hidden File System ESPecter bootkit installers for Legacy Boot versions use unallocated disk space located right after the MBR to store its code, configuration and malicious driver.
T1140 Deobfuscate/Decode Files or Information ESPecter uses single-byte XOR with subtraction to decrypt user-mode payloads.
T1562 Impair Defenses ESPecter patches Windows kernel function directly in memory to disable Driver Signature Enforcement (DSE).
T1036.003 Masquerading: Rename System Utilities ESPecter bootkit installers for Legacy Boot versions copy cmd.exe to con1866.exe to evade detection.
T1112 Modify Registry ESPecter can use DefaultConfig value under HKLM\SYSTEM\CurrentControlSet\Control to store configuration.
T1601.001 Modify System Image: Patch System Image ESPecter patches various functions in Windows Boot Manager, Windows OS loader and OS kernel directly in memory during the boot process.
T1027.002 Obfuscated Files or Information: Software Packing ESPecter’s WinSys.dll component is packed using the MPRESS packer.
T1542.003 Pre-OS Boot: Bootkit ESPecter achieves persistence by modifying Windows Boot Manager (bootmgfw.efi) located on the ESP or by modifying the MBR on Legacy Boot systems.
T1553.006 Subvert Trust Controls: Code Signing Policy Modification ESPecter patches Windows kernel function SepInitializeCodeIntegrity directly in memory to disable Driver Signature Enforcement (DSE).
T1497.003 Virtualization/Sandbox Evasion: Time Based Evasion ESPecter’s WinSys.dll component can be configured to postpone C&C communication after execution or to communicate with the C&C only in a specified time range.
Credential Access T1056.001 Input Capture: Keylogging ESPecter has a keylogging capability.
Discovery T1010 Application Window Discovery ESPecter’s Client.dll component reports foreground window names along with keylogger information to provide application context.
T1083 File and Directory Discovery ESPecter’s Client.dll component can list file information for specific directories.
T1120 Peripheral Device Discovery ESPecter’s Client.dll component detects the insertion of new devices by listening for the WM_DEVICECHANGE window message.
T1057 Process Discovery ESPecter’s Client.dll component can list running processes and their loaded modules.
T1012 Query Registry ESPecter’s WinSys.dll component can check for installed software under the Registry key HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall.
T1082 System Information Discovery ESPecter user-mode payloads can collect system information from the victim’s machine.
T1124 System Time Discovery ESPecter’s WinSys.dll component can use GetLocalTime for time discovery.
Collection T1119 Automated Collection ESPecter’s Client.dll component can automatically collect screenshots, intercepted keystrokes and various files.
T1025 Data from Removable Media ESPecter’s Client.dll component can collect files with specified extension from removable drives.
T1074.001 Data Staged: Local Data Staging ESPecter’s Client.dll component stores automatically collected data into a hidden local directory.
T1056.001 Input Capture: Keylogging ESPecter has keylogging functionality.
T1113 Screen Capture ESPecter’s Client.dll component has screen capture functionality.
Command and Control T1071.001 Application Layer Protocol: Web Protocols ESPecter’s WinSys.dll component communicates with its C&C server over HTTPS.
T1573.001 Encrypted Channel: Symmetric Cryptography ESPecter’s Client.dll component encrypts C&C traffic using single-byte XOR.
T1105 Ingress Tool Transfer ESPecter’s user-mode components can download additional payloads from C&C.
T1104 Multi-Stage Channels ESPecter’s user-mode components use separate C&C channels.
T1095 Non-Application Layer Protocol ESPecter’s Client.dll component uses TCP for C&C communication.
Exfiltration T1020 Automated Exfiltration ESPecter’s Client.dll component creates a thread to automatically upload collected data to the C&C.
T1041 Exfiltration Over C2 Channel ESPecter exfiltrates data over the same channel used for C&C.
T1029 Scheduled Transfer ESPecter’s Client.dll component is set to upload collected data to the C&C every five seconds.

Paper 本文由 Seebug Paper 發布,如需轉載請注明來源。本文地址:http://www.bjnorthway.com/1738/