NTFS之HARDLINK攻防

NTFS之HARDLINK攻防

引用：

http://www.debugman.com/thread/2061/1/1

http://www.debugman.com/thread/2062/1/1

http://huaidan.org/archives/2398.html

http://huaidan.org/archives/2399.html

----------------------------------------------------------------------------------------------------------------------------------

第一章

作者：MJ0011

爆老技术啊爆老技术~

NTFS支持一种HARDLINK技术，可以将两个文件“硬连接”起来，其实原理很简单，两个文件共享同样的fie record，操作一个文件相当与操作另一个文件，包括相关属性，删除其中一个，另一个会保留原有的数据存在~

可使用系统工具fsutil.exe来创建一个硬连接，也可以使用windows提供的相关API、FSCTL来实现

fsutil hardlink create c:\1.txt c:\2.txt，即可建立c:\2.txt的连接,c:\1.txt

那么用于攻防，能做什么呢，简单就想到啦，使用文件路径过滤的同学们就惨了

pryrege.sys是一个最近流行的木马程序，其包含了一个文件系统过滤驱动，当你去删除他的文件的时候，他会假装返回成功了，实际是失败了~另外它的驱动有只读属性，并且不允许你修改它的属性，所以要写入也是不行的了~

你以为怎么清除它？上驱动?NONONO，没必要啊，hardlink来帮忙

我们首先用fsutil创建一个对它的hardlink, c:\2.txt，如图1

你会发现，2.txt也是有只读属性的，没关系，将c:\2.txt的属性只读去掉

此时pryrege.sys的只读属性也没了，如图2

我们来用记事本把2.txt的内容清空~

你会发现pryrege.sys也变成0字节空文件了~~ ,如图3：

至此，该木马作者哼哧哼哧地捣鼓出了个20多K的文件过滤狗屎驱动，只要一行命令就把他搞定了~

当然hardlink也是有攻防两面性的，例如用来删除或改写卡巴7的文件~ 用来读取被XX文件安全岛保护的文件~等等，技术是双刃剑啊~看你怎么用了。

不过，360的自我保护早考虑到这块，彻底抛弃了原始的路径过滤方法了，如图~ 没法给360的程序创建硬连接的，另外，即使你创建成功了，操作也无法成功映射过去，至于这点怎么做到的~碍于职业道德，我就不说啦~大伙自己研究吧~

----------------------------------------------------------------------------------------------------------------------------------

第二章

Hardlink 之文件蹲坑~

首先用oo.exe蹲坑一个文件 c:\1.txt~
可以看到文件打不开了~

图1：

然后fsutil.exe hardlink create c:\7.txt c:\1.txt

创建硬链接~

图2：

你会发现7.txt也被独占了~打不开啊打不开，

图3：

当你去拿着7.txt去unlockme， 去process explorer.,去超级巡警暴力删除地时候，你会发现，找不到啊找不到，删不到啊删不到

图4：who lock me 啊 ，找不到找不到~

因为这些喜欢跑到别人进程里去关句柄的SB删除工具，完全不知道是由于1.txt被蹲坑了，所以7.txt才被蹲坑了

因此这样的文件unlockme,  process explorer , 超级巡警暴力删除都傻眼了，傻眼了

恩，所以说，牛比还是360啊

我们的XCB大法就可以干掉这个文件了

图5~， XCB大法测试工具，force delete后  7.txt瞬间消失~

补充一点，使用磁盘层抹文件的方法，确实也可以删除掉这个7.txt,

不过危险的是，用磁盘层方法会导致1.txt也被干掉，因为是共享的FILE RECORD~，这时候如果攻击者拿c:\windows\system32\config\system去站坑~磁盘层白痴删除工具，就傻眼了傻眼了

所以磁盘删除文件啊，不靠谱啊不靠谱~

XCB大法就不会有这个问题，删除完7.TXT后，只是1.txt被解除占用，1.txt的数据仍然保留得好好的~

因此XCB大法结合HARDLINK其实可以变相解锁文件~例如先拿HIVEhardlink占坑4.txt,然后XCB大法删除4.txt,此时hive就可以正常访问了~

见图~：

但其实文件的句柄仍在，SYSTEM进程仍然可以正常访问System hive~

见图：

所以说XCB大法是安全解锁~不伤句柄~