0x01 前言

22年在客户处HVV的时候，写的一篇分析文章，因为一些原因一直没发出来，今天分析某样本的时候想起来之前的分析文章，顺便在blog上更新下；

域名前置这个技术真的是历久弥新，从21年国内攻击队开始范围使用，到最近的hvv还比较常见，从23年年底开始笔者发现这个域名前置技术，有的攻击队开始老树开新花，一改往日作风，把前置域名干掉，样本里面内置cdn节点，然后直接上后置域名，也能实现上线，并且没有域名解析记录，导致防守方的一些流量设备时不好排查的，怎么查呢，难道查内置的cdn节点？节点选得好，说不定内网一堆正常业务流量也会去连；

不禁感慨，这个技术其实最早是从漂亮国那边搞出来的，我记得大概是15、16年左右就有公开纰漏某些apt组织使用该技术实现c2上线；这里把两年前自己写的文章搬回来，也算是致敬技术把；

还有就是现在看自己两年之前写的文章，本来会觉得不入眼，但是看下来好像也没有那么不堪；甚至觉得自己之前的文字表达欲望真的很强烈，还会做一些衍生，写些密码学的东西；而反观现在自己写的文章，感觉有点草草了事，只是就事论事，目的性非常的强；这样是个好事还是坏事，我也说不准，我感觉就事论事也挺好，写的专业些，面别广，能够自然而然的往深走；但是慢慢的会发现，自己被困在了一个小圈子里面，一些泛化或者曾经比较熟悉的知识因为一直没用尘封多年就会导致忘记；哎人总是患得患失；算了废话不多说了；

原文：

某演习活动中某个钓鱼邮件的分析过程：

0x03 调查分析

这里我们拿到样本之后解压：

看着没啥异样，一个mac的文件夹，一个docx是简历。

但是这里我们注意一个细节，这个docx为什么后面的文件类型是一个快捷方式？

正常的一个docx文件的文件类型应该是work文档：如下图

查看文件属性：发现的确这只是一个快捷方式，所以这里通过双后缀命名 xxx.docx.Ink，而ink快捷方式的后缀会被隐藏，从而只显示docx

可以看到该快捷方式连接的是在，mac的隐藏文件夹.__MACOS__的文件里面的一个spc.exe，这里也是来骗收件人的，一般人肯定就觉得这个文件夹就是mac打包自动生成的，不会取看：如下图，其实攻击者就是在这里面的三层文件下藏了一个exe。

我们来到这个exe的位置：如下图，可以看到这个文件藏的很深，而且攻击者随机生成的一堆文件夹来，混淆视听，把exe藏在最里面，而且藏了三层，很难被找到，如果你没去看那个快捷方式的链接地址：

有趣的是，上图这个spc.exe的图标，这是一个大型的企业办公软件的图标，而且客户那边也都是用的这个软件来进行内部通信软件。所以这里我怀疑这个exe就是马，接着往下分析：

这里我们将这个exe丢到pe查看里面看下：如下图，这个exe是一个正常的exe没有壳，甚至还有签名

这里我们直接通过属性打开，查看数字签名，如下图，发现这个文件尽然还是使用的是Blueix Mobile Technology这个组织的私钥进行签名的，而且从右侧的证书来看，这个私钥还是被ca所认可的，也就是被验证过的。所以这里这个签名也不是伪造的。

看了下证书的有效期，如下图，可以看到有效期是前段时间刚过期的，虽然证书过期了，但是按道理来说，攻击者也是不可能能拿到之前的私钥，对一个木马文件进行签名的，所以这里这里我开始怀疑这个exe就是一个低版本的的正版官方的exe：

如下图这个exe的签名时间戳也是在19年，也算符合我的猜想：

当然这里为了保险起见，我还想到一个好办法来证明这个就是官方发布的老版本的exe，因为这个款exe本身是qax的，所以这个在ti上去查是不是有可能是白名单，如下图果然是这样的：

那么这就奇怪了，攻击者钓鱼千方百计为什么要构造一个快捷方式，来运行一个被藏在几层目录下的一个spc.exe安全pe文件呢？

这里我们不妨想一下，这个exe运行的时候会在内存里面进行哪些操作呢？

这个过程首先操作系统要开辟一个4gb的虚拟空间，其中高位空间2g内核用，低空间2g 给exe用，exe先把自己拉升然后加载到一个位置（一般是400000），然后要看自己需要哪些模块协助，这个过程是从导入表里面看exe引用了哪些模块，操作系统会帮exe把这些要用的模块也加载到低内存空间里面。

如下图是这个exe的导入表：需要加载六个其他的模块，其中有系统模块，也有非系统模块

结合这个exe当时目录的信息，如下图，于是乎我一下锁定了这个Lxbase.dll：

这个dll是这个款内部通信软件自己开发的dll，如果本身这个通信软件没有对其自己的dll进行签名，并且对这个签名进行验证的话，那么这里攻击者可以直接替换掉这个DLL，并插入恶意代码。（很多应用都有这种问题，就连qq、微信等好像都有，要么是签名了，但是没验证，要么是验证的不到位，后文我们会就这个问题深入谈论）

如下图，果然，这个dll是没有签名的：

分析到这里，其实这个就可以大致确定这个是一个白加黑的DLL劫持利用，接下来我们就这一点展开动态调试分析：

将这个spc.exe和Lxbase.dll放到一个文件夹下面，使用x32dbg进行分析：

0x03 动态样本分析：

样本分析：我们从几个敏感函数下手，首先是加载模块使用以及动态寻找函数地址使用的LoadLibrary和GetprocessAddress。

我们注意一个细节，虽然上面我们看spc.exe的导入表里面，并没有像wininet和ws2_32.dll的模块导入，但是其loadlibarary之后加载了Lxbase.dll之后，是不可控的，谁知道在Lxbase.dll的入口函数那里干了什么呢？

所以我们还要通过去判定样本的行为之后再从对相关的函数进行断点查看，

如下，直接在虚拟机上运行样本，通过sysmon可以看到运行样本之后，如下图，出现了域名查询记录（当然这里还有很多手段，比如对注册表进行检测，注册表是否被修改等行为也要检测，这里这里最后发现断网环境下样本运行我们只看到了域名请求记录）

像常用的来监测dns，这里也可以用ApateDNS看到：

所以这里根据我们观察到的样本行为，在动态分析的时候就要重点关注网络模块里面的关键函数，像wininet里面的InternetConnect、InternetOpen、HttpRequestOpen、HttpRequestsend，ws2_32里面的connect、send、recv等，把这些函数找到并下断点即可：

打好断点后直接开始调试，分析过程如下：

首先我们发现了在Lxbase.dll里面调用了LoadLibrary加载一些dll模块，其中包括

1、LoadLibrary加载了wininet.dll模块;

调用wininet.dll里面的相关建立连接函数：

2、调用InternetOpen发起了网络连接，参数如下图，

3、请求的方式是https（这个看是http还是https是通过看HttpOpenRequest被调用的时候传入的倒数第二个参数判断的）的get，请求的uri是audiencemanager.js

4、在发送请求（调用HttpSendRequest）之前，对请求头进行了修改（调用HttpAddRequestHeader），这里加了一个host：whoamb.microsoft.com，和之前建立连接使用的域名不一样了（之前使officecdn.microsoft.com），其实从这就能看出来这里使用了域前置技术了。

这里当时笔者对whoamb.microsoft.com这个域名进行了判断，简单google下，会发现全网都没有这个域名出现过，也就是微软每用过这个二级域名，所以这里攻击者就可以用这个做后置域名，只要攻击者能在微软使用的cdn厂商那里申请到whoamb.microsoft.com这个域名就可以。

并且查了下whoamb.microsoft.com的流量活动情况，也印证了微软之前没有用过这个域名，最近突然存在少量的访问记录，所以这是为了这次演习活动专门做的木马。（这里有个bug，尤其是对本身不了解域前置技术的人来说。所有的情报查询网站，像微步、奇安信ti等等，从头到尾都是对这个whoamb.microsoft.com域名给的白名单，上面会有一个大大的安全标记，因为这个域名的一级域名是微软的官方域名，估计是把所有*.microsoft.com的域名都加白了，其实这么做也没有问题，但是在域前置技术场景下，也就是cdn厂商不能保证一个三级域名的使用者和这个三级域名中二级域名的使用者有强关联，那么这么做就是有问题的了，建议结合相关域名的流量以及历史使用记录做一个综合的风险评估再打标签，而不是简单的判断二级域名。）

样本分析就此结束了，那么问题就来了，怎么协助客户来查，客户哪些资产失陷了呢？

回连流量是走的https，所以我们在对应ids设备上也看不到具体的请求内容。

0x04 流量问题

一、HTTPS解密问题

客户https流量我们看不到，这个涉及到IDS类设备是否能对TLS的流量进行解密的操作，怎么说呢，这里面大有文章，并且还自相矛盾。首先正如大家所知的现在的确有不少的IDS、NDR等等流量设备能支持对https流量的解密。这里我们来简单分析下：

1、TLS解密：

首先我们先来看这个tls流量解密的原理，简单理解就是，在TLS协议中，我们使用非对称加密算法来传输对称加密算法使用的密钥，使用对称加密算法来加密传输的内容（至于为什么这样搭配使用，可以去看下密码学内容）。所以我们如果要想解密流量，最核心的目标是要获取到用来加密内容的对称加密算法中使用的密钥，这个密钥的获取方式有两种：

1、从非对称对称加密算法解密来，这里就需要非对称加密算法对应的私钥，这个私钥简单理解就是，对应站点在申请证书的时候，经过证书颁发机构验(CA)证过的与证书中的公钥成对的，对应私钥。
2、从本地日志来，有些浏览器是在本地会存一个对称密钥日志文件，这里面存的就是一些对称加密使用的密钥。

那么我们常说的在流量设备中解密对应的https流量其实就是使用的上述第一种方法，也就是通过私钥来解密流量（其实更具体一点是，通过私钥解密获取到对称加密算法中使用的密钥，再使用密钥解密获取通信内容），所以安全厂商们的相关设备会要求客户提供私钥以及证书。

接下来我们来分析下里面的问题：

首当其冲的就是客户能提供哪些私钥，这里客户只能提供自己站点的证书和私钥，所以我们能解密的https流量其实就只有访问客户https站点的流量（当然其实大多数的需求也就是这样，看看客户自己的站被哪些流量打了，并且后续方便溯源取证，这里笔者把这一点拿出来说是因为我们上文分析的cs https流量上线的场景里面，对应的流量是向外访问外网的站点，所以这里解密不了）。当然其实这也是https被设计出来的原因，就是为了让信道里面的内容不能被别人解密出来，要是每个人都有所有的私钥，那就天下大乱了。

其次，笔者为什么在上文说有一个自相矛盾的点，那就是所有的旁路流量设备都没办法”解密“使用DH密钥交换算法生成密钥的https站点对应的流量，哪怕你有所谓的私钥。而在最新的TLS协议,也就是TLS1.3中做了明确规定，所以的密钥交换算法强制使用DH密钥交换算法。这就意味着，基本上所有的旁路流量设备没有办法解密对应的https流量，在使用了DH密钥交换算法的TLS协议中。这里笔者简单的去google看了下TLS1.3的普及率，在去年年底（2021年）的统计报告中，互联网上TLS1.3的使用率就已经到到达了差不多%50。而且随着时间的推移，这个越来越多的https站点都会使用TLS1.3。那么对于ids类产品所支持的https解密功能只能是慢慢的变成形同虚设。

这里笔者想就为什么旁路设备（也就是ids、NDR类的设备）不能解密使用了DH密钥交换算法的TLS协议展开详聊，因为前段时间笔者的一个同事曾向笔者问起过这个，可能这也是很多人的疑惑。

其实是和DH这个算法本身有关系，不知道大家有没有注意一个问题，这个笔者对DH的描述都是”DH密钥交换算法“，这个算法是一个独立于加解密的一个密钥交换算法（当然其和非对称加密算法是有渊源的）。我们先来看下正常使用非对称加密算法来失陷密钥交换的过程：

Alice： Alice使用Bob的公钥加密一串他自己随机生成的密钥，将加密后的密文传输给Bob；
Bob: Bob使用自己的私钥解密Alice传输过来的密文，获取到密钥；

通过这样的，Alice和Bob之间都获取到了密钥，后续就可以用来作为对称加密的密钥了；也就是说整个过程密钥的生成完全取决于Alice选择。并且密钥的密文在隧道里面传输了。一旦攻击者获取到了Bob的私钥，并截获到传输的密文，那么Alice和Bob后续的使用的对称密钥就都能被攻击者获取，当然也包括之前的，只要攻击者把之前的密文流量留存了（在密码学里面，对这个问题的描述是”前向安全性“），其实上文我们提到的旁路流量设备通过私钥解密其实就和这个攻击者是一回事。

我们再来看下DH密钥交换算法实现密钥交换：

这里笔者不详细讲DH密钥交换算法，我们主要来看为什么私钥不能解密了。在DH实现的密钥交换的TLS的这套体系中，我们并没有使用非对称密钥来实现加解密，使用非对称密钥对是用来签名和解签名。所以我们导入所谓的私钥是没有用的。我们要导入DH密钥交换算法的私钥才行，但是因为DH密钥交换算法的私钥分两个，一个是Alice的DH私钥，一个是Bob的DH私钥；并且最终的密钥是要先后经过两个私钥处理（这个处理的过程是不可逆的，其实就是借用了非对称加密算法）之后生成的，而这里我们没办法拿到任何一方的DH私钥，两方面原因：

1、这个私钥没有在通信过程中传输。

2、DH算法双方再利用私钥生成对应的公共密钥之后，主机侧不会留存私钥，并且毫秒级的删除所有生成以及算法使用的过程信息和材料。（这是根本原因，从根源上就没有给攻击者破解，从而获取到私钥的机会）。

这里简单说一个容易被混淆的问题：

这两天笔者看datecon的一个分享里面，说是因为椭圆曲线算法，才使TLS其具有前向安全性，如下图是ppt中的描述；这种说法是有问题的。椭圆曲线和前向安全性没有任何关系；举个例子，DSA大家都知道，是一个非对称加密算法，其原理是基于整数有限域离散对数难求解的难题。但是随着一些算法的研究，我们破解DSA的时候，就不再需要使用一一穷举的方法来破解，拿1024位的DSA算法举例，其安全等级还没128位的AES的安全等级高，而且这个随着这个位数增涨的趋势，DSA其安全等级想要增长一倍，其位数是呈指数增长的（可能要翻很多倍，比如：我们想要获得一个和256位的AES相同安全等级的DSA，那这个DSA的位数可能要五六千位，甚至上万位，反正数远大于2048位的）；就是因为这个原因，ECDSA才出现的（即基于椭圆曲线上的DSA算法），其原理变成了基于有限域上的椭圆曲线上的点求椭圆曲线上的离散对数问题，因为椭圆曲线离散对数问题远难于离散对数问题，所以在引入了椭圆曲线之后，我们使用160位的ECDSA就和之前1024位的DSA具有相同的安全等级了，DH和ECDH也是同样的关系。

回到正文，最后得出结论：

所有的旁路流量设备（IDS,NDR）等，是没办法解密使用了DH的TLS协议流量。

2、另辟蹊径：

那么是不是就真的无解了呢？其实不是。在密码学里面有个叫中间人攻击的手段，估计大家或多或少都有所耳闻，其实就是流量劫持了。

这种攻击手段也被用在了很多的正常生产场景：

1、我们使用Fiddler，怎么抓取解密获取https的流量呢？

2、很多企业集团，对内网流量会做监控，他们是如何监控内部员工的上网流量中https的那部分流量的呢？

答案就是”流量劫持“

这里我们简单描述下这个原理：

A想和B进行通信，但是在被劫持的场景中实际上A是和C通信，C把收到的内容转发给B。B在收到信息之后会回消息，回的消息也是给C的，C收到消息之后转发给A。

就在这个过程中，C是可以获取到全部A和B之间的通信内容的。通过这种手段可以解密所有https的流量，但是这个设备必须串行部署在流量中才可以，而不是像ids类设备部署在旁路，对流量进行镜像。

但是这个技术呢也是有局限性的，比如一些金融公司或者一些对数据流量管控要求很严格的公司以及集团，没办法在内部做一个“中间人”的一个操作。

二、dns流量问题

我们可以看到域名解析的流量，但是这个域名解析解析的是前置域名officecdn.microsoft.com，而正常的微软相关业务也就是会进行这个操作的，并且我们不可能每个终端上都去安装sysmon，并排查发起请求的进程！所以从dns流量这个角度，样本的网络特征行为就失去了其唯一性！这就是非常难办了。

这里延申出来了一个新的问题东西，在安全圈从事的人，这两年或多或少都听说过XDR（各厂商之间可能演化出来不能的产品，对应名称可能不一样），这个东西在一定程度上是可以解决上述的场景的检测问题，笔者认为在一定程度上这类产品本身被设计出来的核心价值就是，收取各方日志形成关联分析，其实就是将流量日志和终端日志进行关联分析。像上面这个场景，其实是可以通过主机日志和流量日志，关联从而产生告警。

0x05 域名前置的对抗技术

如下图是ATT&CK模型中，应对命令执行阶段的代理技术中的域前置技术方法：

一个是缓解手段，一个是检测手段：

缓解手段：这里说的缓解手段就是，解密https流量，来排查检测是否出现了域前置的形式的连接，也就是上文我们提到的提的第一点。
检测手段：这里的检测手段大致意思就是，关联分析主机中的进程行为和流量。如果一个进程出现了不符合其原始行为的异常流量，我们就要关注。

其实笔者觉得要做到上面两点，以我们现在大多数企业的安全建设现状来说是非常困难的。这个问题归根到底还是因为IDC没有做好对域名的管控，所以想要对抗域名前置要从IDC那边做：大概两方面内容把：

1、IDC要加强对域名申请的管理，加强对域名归属的身份认证，比如说我想要开通一个域名：nihao.ga0weI.com，那么idc应该强制要求，我能提供身份证明来证明ga0weI.com的拥有者。

2、对流量进行管控，核对流量中的SNI（服务器名称指示，在TLS的连接建立的时候客户端伴随client hello发送的）是否和https中封装的http头中的host字段一致，如果不一致，对应加速节点直接丢弃这条流量。

0x06 后续

言归正传，回到客户处如何处理，客户当时是没有解密https流量的条件的。

于是这里我们查看了下这个前置域名，officecdn.microsoft.com,这个域名是微软用来下载一些ppt或者一些产品的下载域名。

于是想了下特殊时期，干脆直接把这个前置域名封了，影响的只是一些microsoft产品的下载。

其实上面这个手段是一个下下策，除此之外真没办法了。为什么说是下下策呢：

1、影响一些microsoft的相关产品的下载功能的正常使用。

2、这个措施不具有通用性，如果下次出现的前置域名是某银行的域名，那还能封吗？所以这里我们要斟酌二三。

除此之外及时和对应cdn厂商联系，反馈相关问题，让其ban掉所有节点对后置域名的转发和解析也是一种处理手段。还有一种场景是，如果我们和对应cdn厂商有相关人脉资源（比如很多客户可能也是对应cdn厂商的甲方），那么可以去和cdn厂商聊，索要对应前置域名的转发节点的转发记录，看看后置域名被转发到哪去了，这样我们有一定的几率可以找到攻击者使用的c2，找到真实c2之后，结合一些手段去做反制、溯源。

0x07 DLL劫持

最后我们简单来看看所谓的dll劫持：

DLL劫持就是说，在某个exe运行的时候，其原本想加载的DLL文件被替换成恶意的DLL文件了，从而导致我们加载恶意的DLL，执行了恶意代码。

劫持是怎么做到的呢，我们先来看看正常dll文件的寻找顺序：

一、Dll加载

1、加载前的检查

参考微软的官方解释：

https://learn.microsoft.com/zh-cn/windows/win32/dlls/dynamic-link-library-search-order?redirectedfrom=MSDN

首先，在系统搜索 DLL 之前，它会检查以下内容：

如果内存中已加载具有相同模块名称的 DLL，则无论它位于哪个目录中，系统都使用加载的 DLL。系统不搜索 DLL。
如果 DLL 位于运行应用程序的Windows版本的已知 DLL 列表中，则系统会使用已知 DLL 的副本 (和已知 DLL 的依赖 DLL（如果有) ）。系统不搜索 DLL。有关当前系统上已知 DLL 的列表，请参阅以下注册表项： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs。

2、加载顺序

系统搜索dll的方法如下：

1、）SafeDllSearchMode模式开启的时候（默认都是开启的），搜索顺序如下：

2、）SafeDllSearchMode模式关闭（关闭的方法：创建 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager**SafeDllSearchMode** 注册表值并将其设置为 0）的时候，搜索顺序如下：

简单总结概括：

1、加载dll之前，首先去内存种检查是否加载过同名的，然后检查是否属于KnownDLLs，如果不满足这两个条件的时候才会开始加载对应dll。这里我们不妨想一下这两点是在干什么，笔者简单想了下，第一个检查同名，应该主要是考虑性能，避免重复加载；第二个检查是否在KnowDLLs里面，应该主要是不想一些核心关键的dll，如kernel32.dll、ntdll.dll等系统dll被轻易重写或者被劫持，所以固定好遇到这些必须加载系统准备好的。
2、默认情况下（SafeDllSearchMode开启），先看exe里面写好的dll路径去加载，如果没有写路径的话先去系统目录（C:\Windows\System32）加载，再去16位的系统目录（C:\Windows\System）中加载，然后去windows目录（C:\Windows）加载，然后是程序运行的当前目录，最后是系统Path路径。将这个加载顺和没有开启SafeDllSeachMode模式下的对比我们会发现，唯一的区别就是把程序当前运行的目录往后放了；可以看出来微软的这一设计其实就是不想一些在系统目录的dll被应用程序目录里面的dll所劫持，所以将当前目录的优先级几乎是放到了最后。

这里我们结合上面的钓鱼样本案例，他是怎么做到的劫持的：

上文中的Lxbase.dll是，对应软件自己的扩展DLL模块，没有和系统dll同名，所以最后直接来到exe的当前目录来加载。

所以这里的dll被劫持不是系统原因，而是对应的软件没有对自定义的dll进行验证就直接加载了导致的（可能是因为版本比较久远了，19年的版本，当时可能没做对dll的验证）。

3、简单测试

后续笔者又对应的软件进行了测试：

可以看到，这里仍然用到了一个叫LxBase.dll的dll模块

这里我们尝试在这个基础上构造恶意的dll：

二、DLL构造

DLL构造的思路是：

查看当前的LxBase.dll中有哪些导出函数，我们构造一个新的MyLxBase.dll，同样导出对应的函数，导出函数的逻辑里面啥也不用干，直接通过loadLibrary加载原版的LxBase.dll，然后通过GetProcessAddress，挨个传入函数名，获取对应函数的地址并跳转，就相当于调用原版的LxBase.dll里面的函数。这里我们将加载的恶意代码写到dll的dllmain方法里面，当dllmain方式接收到fwdReason为1的调用的时候（其实就是调用loadlibrary加载这个dll的时候），就运行我们的恶意代码。最后实现的效果就是，在受害者没有察觉的情况下就运行了我们的恶意代码。

我们先来看下LxBase的导出方式：如下图，都是通过名称导出的函数

这里我们构造dll的时候可以直接使用一款aheadlib的工具来生成hook的代码，然后稍作修改还即可：

我们来看下这个cpp文件：

这里面首先：将原版的dll模块加载进来（注意这里，为了区分，笔者将原来的dll模块换了个名字）

然后就是通过GetProcessAddress获取到原来Lxbase.dll里面导出函数的导出地址：

最后我们自己在dll里面也导出这些函数，如下图这里导出函数里面啥也没干，直接就通过内联汇编，jmp到上面获取到的导出地址。（当然这里我们也可以添加上我们自己的逻辑，如果我们想要hook某个具体的导出函数，那就再对应的jmp前面添加要执行的恶意代码就行）

接着我们把恶意代码写到dllmain方法里面：

注意这里最后笔者还调用MessageBox弹了个窗：

然后生成dll：

接下来我们将这个dll丢到对应应用程序的exe目录下，并将之前的dll，修改名字为上面我们再cpp文件里面写的（LxBaseorg.dll，还有就是路径，这里笔者测试发现，这个应用程序在运行前会对exe所在的目录里面的dll进行检查，检查的方式是检查dll的名称，并没通过签名来检查，虽然这个目录下的dll都是签名了的；但是我们可以把原来的dll改名之后放到其他文件夹下，这里笔者是放到了F盘的根目录下）：

F盘根目录：

然后我们直接运行这款应用程序：

运行之后直接弹窗：

点了确定之后又连续弹窗两次：

然后就是正常的应用程序的登录，但是因为shellcode这里没做免杀，后续进程直接就被干掉了，不知道是这个软件自查干掉的还是windows defender干掉的。

不管怎么说，弹窗了就说明这里存在dll劫持的场景，虽然和上文样本里面的不一样了，但是还是能被劫持，导致劫持的根本原因就是，最新版里面没有使用正确的方式对自制的dll进行签名验证！如果这里不是只验证dll名称，而是根据dll的内容做签名验证的话，那么就不存在被劫持的场景了。

当然这里面还有很多的权限，问题，比如说一般的应用是会对其安全目录中的文件修改操作要求管理员权限的之类的，上文这个劫持的场景仅仅限于理论研究。

0x08 总结

最后对钓鱼事件总结下，上面这起钓鱼事件其实就是一个典型的非常具有针对性质的攻击，如：攻击者对受害者内部使用的相关通信工具进行漏洞挖掘，引入了dll劫持技术；此外还使用了相关c2隐藏的域名前置技术；对抗分析手段呢则是利用白加黑来实现绕过一些机器分析和检测。感觉在某些角度上符合APT的一些特征，但是这里“美中不足”的是，攻击者使用的马做的反分析手段有限，像对抗调试和沙箱的手段都是比较poor的，导致样本被捕获后会被快速分析。

笔者才疏学浅，若文中存在错误观点，欢迎斧正。

忆往昔-记一次（白加黑dll劫持+域名前置）样本分析

通过一个样本来看dll劫持和域名前置