从HW钓鱼事件中看Honeytoken

发布于 2022-07-28  1232 次阅读


写在前面

  先看事件

image-20220727134221195

  这个项目其实我在HW开始的第一天就发现了,自己和小伙伴们一直都在用灯塔进行资产收集,所以对于fofahub有一定的敏感,但是由于自己没有对恶意文件分析的能力,就暂时没有轻举妄动,在获得准确消息后,也是对其中的恶意文件进行了分析,也研究了一下关于这个钓鱼所用到的技术。HW嘛,最重要的还是学习!

针对FofaHubKey.docx同类文件的分析

沙箱检测

  我个人呢,是没有逆向文件进行分析的能力,所以吧,对于这种恶意文件只能依赖于沙箱检测,在得到准确消息之后,根据事件中的关键词,也就是Canarytokens信标,找寻一些开源的资料,最终发现CANARY TOKENS - 金丝雀代币这个网站,这个网站可以提供一些免费的Canarytokens信标的服务。

image-20220727135346457

  这个网站可以提供基于Word、Excel、SQL数据库、邮件、Web通信等的信标,我这边仅展示一下基于Word的文件。
  首先是FofaHubKey.docx这个文件到底有什么用?他作为一个令牌类的钓鱼文件,其实动作并不大,能产生的作用很有限,仅仅是能告诉你谁访问了或打开了你部署的这个文件,也就是通过一些手段告诉文件所有者访问者的IP地址。
  然后看一看检测率吧,以下是原生文件没有做任何免杀处理的VT沙箱的检测率

image-20220727140041473

  可以看到仅有四家的沙箱报毒,这个检出率我觉得应该还是跟它的动作不大有一定的关系。


  不过还有一种情况当你在信标网站上关闭了token的响应通知,那么大概率沙箱是无法检测出来的,这种就比较头痛,就如下面这个我做的实验。暂时我也不知道有什么好的办法去检测。

image-20220727195353983

如何触发

  这个文件在打开的时候会请求一次令牌地址,令牌地址示例如下http://canarytokens.com/traffic/feedback/articles/ulzbsof39eun0dyhijcq4bt44/post.jsp,这个URL中间ulzbsof39eun0dyhijcq4bt44为唯一的令牌,只要是这个域名,是这个令牌就可以触发一次访问,触发就是如此简单。

返回内容

  返回的内容其实很简洁,只有触发文件的IP地址,UA头,token,触发时间这样。

image-20220727195941611

二次更新

  在写完这篇文章之后不久,一个偶然的机会得知到.docx等后缀名文件本质上是一个压缩包,因为这是CTF竞赛中常用的信息隐写技术,也确实是我之前并没有接触到,这样的话,这个蜜标文件就可以进一步分析了。
  下面我就直接展示一下文件内容。

image-20220825141749859

  因为这个文件它还是个.docx文件,所以组成部分依然是标准的.docx文件的组成内容。而重点就是在这一系列的xml文件中。
  重点文件为./word/路径下的footer2.xml文件。

image-20220825142237963

  这个文件中就有最终请求的蜜标地址,而这个语法是word中可插入图片的INCLUDEPICTURE域语法

{ IncludePicture "FileName" [Switches ] }

  • 参数含义:
    "FileName" 图形文件名称和位置。如果其中包含较长的带空格文件名,请用引号引住。以双反斜线替代单反斜线指定路径。例如:"C:\Manual\Art\Art 22.bmp"
  • 开关:
    \c:Converter 标识所需的图形过滤器。图形过滤器名中不需要文件扩展名 .flt。例如,想使用图形过滤器 Pictim32.flt,只需键入:“pictim32”。
    \d:图形数据不随文档保存以减小文件长度。
  • \* MERGEFORMAT
    域代码的格式化开关

  这样来看,相当于每次打开文件的时候就要从某个网络地址加载相应的图片,也就相当于一次请求,而这个请求就会被蜜标的后台解析获取相应的访问者信息。


  文件分析就是这些,不过我在想一个问题,word的本质上文件本体是xml文件的压缩包,那么使用xml语法会不会形成其他的一些攻击形式,比如说利用xml语法达到上线等目的,不过这个动作应该会造成word文件不符合构成标准以及底层文件语法是否合规的问题。不过我想这种东西后续肯定会出现,现在先按下不表,当一个课题以后想起来再研究吧。


关于Honeytoken

先说一下Canarytoken

  关于HW钓鱼事件总的来说就是这些,重点是这个事件所使用到的一些东西,也就是CanaryToken,这个东西其实是基于Honeytoken的上层应用工具,工作原理是在页面的图像标记中嵌入一个唯一的URL,捕获之后的返回信息。
  关键词说Honeytoken可能不太清楚,什么是甜蜜令牌?或者说是蜂蜜令牌?那么换个说法——蜜罐技术中的蜜标,这样的话是不是就很清楚明了了。
  对于Canarytoken就不说太多了,毕竟这只是一个工具,简单研究一下就会用了。

再继续Honeytoken及相关的蜜罐技术

  蜜罐(Honeypot)、蜜网(Honeynet)、蜜标(Honeytoken)是蜜罐系统的三种形态,最主要的作用还是以主动出击的形式在不对等的网络攻防战中寻求自己的一线先机,将攻防活动中的认知成本、经济成本以及时间成本转移到攻击者身上,这就是欺骗防御技术,这是真正意义上主动出击的安全技术。
  另外欺骗技术对于检测内网渗透活动、发现权限提升、建立威胁情报库等工作的意义几乎是不可比拟的。
  对于蜜罐,它是一种服务器、计算机或网络,其实质是针对攻击者的诱饵,通常还提供分析和记录取证功能,目前的网络环境下,越来越多的人开始把蜜罐作为组织的网络或网络的组成部分。
  而蜜网就很直白了,由两个或多个蜜罐组成的欺骗网络。用来保护大规模网络或包含不同复杂信息系统类型的网络。
  在网络技术环境的发展过程中蜜罐和蜜网是网络安全团队最早使用的欺骗的技术之一。
  那么什么是蜜标?

一般用来描述用于吸引攻击者进行未经授权而使用的信息资源,可以是一个伪造的用户ID(比如,设置一个admin账号,如果有人试图以此登录,就证明正在被攻击),特殊的URL,邮件地址,数据库表项,Word或Excel文档等。

  特点?

蜜标必须是特有的,能够很容易与其他资源进行区分,以避免误报
蜜标必须具有高度灵活性,可以在攻击过程的任意环节中作为诱饵进行诱导
蜜标必须具有可追踪性,用于识别细粒度的攻击操作,例如:敏感信息的读取、传递和扩散等

  它与蜜罐有什么区别?

既可以独立使用(轻量级),也可以和蜜罐搭配使用(拓展性强),变成一个可随处布置的探针,最终数据汇集到一起

  应用蜜标需要注意针对蜜标是否具有有效的监视和控制手段,前面有说到可以独立使用,场景就是诸如上文讲到的钓鱼文件,也可以配合蜜罐进行使用,比如作为其他网络安全技术中的诱饵内容补充,辅助捕获特定的攻击行为。
  现代欺骗技术随着云计算的应用,还形成了蜜场(Honeyfarm)技术。蜜场具有可扩展性,支持私有云、公有云和混合云环境中的用户网络和数据中心。蜜场通常将诱饵环境和监控模块集中在一个固定的节点或网络中,以实现对物理设备的管理维护和数据集中分析。为降低运营成本和运维难度,减少真实诱饵节点部署数量,可以采用将轻量级的代理部署在网络的任意节点中,对代理节点处的网络流量进行判别和转发,将网络攻击重定向至蜜场。
  由于欺骗解决方案仅采用与平台的实际业务交互需求作为提供告警的基础支撑依据,因此有着超低误报的优点,某些时候也可以称之为0误报。其告警的关联信息可以作为失陷指示器(Indicator of Compromise,简称IOC)体系纳入网络威胁管理系统中,与其他防护、检测系统协同,阻断网络攻击或提升网络威胁发现能力。

一点碎碎念

  以上就是这次事件中学习到的内容,其实关于欺骗防御技术、广义上的蜜罐系统是一个很大的话题,我这里仅仅写了很小的一部分,感兴趣的可以自行去了解一些。
  不得不说有些技术在不同领域之间可以通用,就像这篇内容中的蜜标技术,起初是用在防守中,渐渐的思路打开后,它可以不拘泥与防守,可以向其他方向去扩展,换个角度可能就会实现自己想要的效果。还是要多看多学、多思考咯
  我这边参考的比较多的,写的比较详细的是这篇文章主动防御(02)-欺骗|洋葱式信息安全观察 – 安全村,感兴趣可以研读一下。