译者：blueSky
预估稿费：200RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
前言
目前，网上已经有很多关于TrickBot（该恶意软件一度被认为是Dyre银行恶意软件的继承者）木马的分析报告。然而，很少有文章对用于欺骗其受害者的木马核心组件web injects进行分析，因此在本文中我将深入对web injects进行研究和分析。
Web injects
Web injects通常是一段HTML或者javascript代码，这些代码通常被注入到浏览器打开的网页（主要是银行网站）中，允许木马更改或替换网页中的内容或者在网页中显示其他字段。 网络攻击者使用Web injects窃取用户在网页上输入的登录凭证，或者向用户发送诱骗其他凭证的请求（非银行发送的请求），例如pin码等。因此，Web injects（也称为发生在浏览器中的攻击）是一种“高明”的技术手段，网络攻击者可以利用该技术实施社会工程攻击或者或自动改变受害者进行的货币交易。
与Dyre木马软件使用的Web injects类型一样，TrickBot使用两种类型的Web injects：“web伪造”和“服务器端注入”。TrickBot将其Web injects定义并存储在类似XML的树结构中，配置列表中的每一项定义了目标（银行）网站，web inject类型和托管web inject服务器的IP地址。图1所示的是一个配置列表，该配置列表是在TrickBot进程的内存中找到的。在本文的其余部分中，我将对TrickBot使用的这两种Web injects类型进行阐述。对于每个Web injects类型，我还将阐述银行可以在服务器端用来检测TrickBot的防御措施。
图1：TrickBot配置列表
Web伪造
TrickBot的web伪造是一种网络注入技术，该技术在受害者浏览银行网站时，会将受害者重定向到恶意的服务器。通过伪造银行网站的登录页面，恶意网站服务器有效地将受感染的用户从银行的正版网站诱骗到伪造的恶意网站中来。在TrickBot的Web injects配置列表（如图1所示）中，Web伪造使用sinj标签定义。当受害者登录到伪造的银行网站时，他通常会看到一个“please wait”消息，一旦用户在登录框中输入登录凭证，那么凭证数据便会被发送给攻击者（如图2所示）。
图2：伪造银行登录网页
伪造的服务器在发送登录凭据的时候会在攻击者端触发警报，允许网络攻击者利用窃取到的登录凭证在真实银行的登录页面上登入受害者的银行账户。当受害者还在伪造的服务器上耐心等待时，攻击者已经开始在查看受害者的银行帐户和交易限制信息。在这一点上，异常漫长的等待时间可能是受害者用来判断是否被攻击的指标。由于浏览器的URL地址栏仍包含合法银行网站的域名，因此重定向到伪造的银行网站不会给用户留下任何其他视觉痕迹，即使受害者会检查URL地址栏中的SSL证书，他也只会看到真实银行网站的证书。
当攻击者希望将资金从受害人的银行账户转出时，他们通常在银行业务会话中面临额外的安全问题。通过一个控制面板，欺诈者可以与他们的受害者进行交互，而此时的受害者仍然只看到一个“please wait”消息。在攻击者的操作下，“please wait”消息页面会被其他的伪造页面替换，这些伪造页面用于窃取攻击者执行电子诈骗所需的信息。这些伪造的请求页面是攻击者精心构造的，以用来诱导受害者回答他们，这些答案通常包含签名令牌，是攻击者提供诈骗受害者帐户所需的最后一条信息。
检测Web伪造
Web伪造通常也被称为重定向攻击，由于与合法银行服务器的唯一连接是由木马本身进行的连接（受害者发起的连接被重定向到了恶意服务器），因此该类型的网络攻击很难从银行的服务器端进行检测。一般地，受害者浏览银行网站时与合法银行服务器建立的连接通常在浏览器的URL地址栏中会显示“安全连接”的图标，并显示合法银行网站的SSL证书。 TrickBot在其重定向攻击中生成的初始SSL连接或许可以在银行网站的服务器日志中检测到。当客户浏览网上银行平台时，浏览器中会加载一个欢迎或登录门户页面，并包括该网页上的所有资源信息（例如image，外部scripts等等）。对这些资源的每个请求都会在服务器日志记录中生成一个条目。但是，TrickBot的SSL连接似乎并没有加载所有这些资源。这种缺少资源的异常加载现象可能是一个很好的特征以用来检测TrickBot。
服务器端注入
TrickBot的服务器端注入是一种网络注入技术，它将额外的客户端代码（例如HTML，JavaScript）插入或者注入到目标网页中。在TrickBot的Web injects配置列表（如图1所示）中，服务器端注入使用dinj标签定义。当受害者浏览到目标网站（即银行网站）时，该银行服务器的响应在发送给用户之前被TrickBot拦截（如图3所示），然后银行的响应将发送到攻击者的服务器上（如图4所示）。攻击者的服务器将在网页中注入额外的代码（服务器端注入），并将注入后的结果发送给受害者。
图3：服务器端注入过程
图4：攻击者服务器获取到银行发来的响应
首先，将整个页面发送到攻击者服务器（只是为了恶意服务器可以将其恶意代码注入到正常的响应中）的这种策略可能会导致很多不必要的开销。这与其他较老的银行木马（如Zeus和SpyEye）使用的客户端Web injects策略不同，客户端Web injects可以有效减少攻击者服务器所需的带宽和处理能力。较旧的银行特洛伊木马通常将注入代码作为其配置的一部分，使用data_before/data_ends标签以及data_inject标签来定义。但客户端注入的缺点是，安全研究人员可以很容易通过解析接收到的配置来判断目标网站是否被注入了恶意代码。因此，服务器端注入是一种较为“聪明”的手法，使用该方法可以尽可能的隐藏其配置方案，以免遭安全专业人员的分析。
服务器端注入的代码通常用来实施社会工程学攻击，例如实施Web伪造。然而，另一个流行的注入代码策略是“表单抓取”。与密钥记录不同，“表单抓取”代码用于获取HTML表单中的信息，该代码允许木马捕获并窃取表单中存在的敏感信息，而密钥记录则会捕获用户输入的所有数据。另外，抓取的数据会被标记，例如标记为密码等，这在一定程度上大大简化了提取过程。密钥记录通常会在其日志中生成大量垃圾数据，往往分析人员需要耗费大量的时间去查找有用的信息。此外，表单抓取另一个优点就是在执行的过程中不需要操作者对其进行实时响应。例如一个表单抓取器，它可以获取在亚马逊网络商店中提交的信用卡号码。这些信用卡号码可以被捕获并存储在数据库中以供将来使用。图5中展示了服务器端Web injects攻击的流程，其中使用了社会工程学和表单抓取。在这种情况下，受害者一直在“等待”服务器的响应，而攻击者则在后台默默的对其账户实施网络攻击。
图5：服务器端Web injects攻击的过程
服务器端注入的检测
由于浏览器呈现的大部分代码仍来源于银行的合法服务器，因此从银行的角度来看，服务器端的Web injects比Web伪造更易于检测。由于银行的服务器能够指定部分渲染的代码，因此它也可以指定浏览器对渲染的代码进行完整性检查。这种完整性检查可以是一个集成在银行门户网页上的JavaScript，以用来检查网页是否被注入恶意代码（例如“表单抓取”代码）。负责完整性检查的代码当然也可以由攻击者通过注入“反完整性检查”的代码来绕过，所以这种检测方法的关键是要很好地隐藏检查或者经常改变它们的代码实现，这种技术在一篇博士论文中被称为“防范基于浏览器的数据渗透攻击”，详情请点击这里。与这篇博士论文中提到的技术类似，该网站上阐述的代码修改检测技术也可以用来检查网页是否被注入恶意代码。
在我调查TrickBot的时候，我注意到有时TrickBot会创建一个不是由银行服务器设置的cookie（如图6所示），这个名为'tknz_referrer'的cookie似乎存储了与注入页面相关的进度或者状态信息。由于默认情况下，浏览器会将请求中的所有Cookie绑定在一起发送给服务器。因此，检测银行服务器端的这种cookie似乎是识别网页是否被TrickBot感染的一种理想方法。
图6：TrickBot 生成的“tknz_referer”cookie