隐藏的艺术：滥用 404 页面的新型 Magecart 活动
执行摘要
Akamai 安全情报组检测到一种以众多网站为目标的 Magecart Web 数据窃取活动，其攻击范围涉及食品和零售行业的多家大型企业。
该活动与以往的活动有所不同，它采用了三种高级隐藏技术，其中一种是我们以前从未见过的技术。具体而言，该技术会操纵网站的默认 404 错误页面来隐藏恶意代码，为检测和抵御带来了不同寻常的挑战。
其他两种混淆技术表明，攻击者正在利用不断变化的攻击方法来躲避检测并延长攻击链。
随着 Web 数据窃取攻击变得日益复杂，企业必须保持警惕，并探索更先进的方法来抵御这些不断变化的威胁。
简介
一种复杂、隐蔽的新型 Magecart Web 数据窃取活动已经盯上了 Magento 和 WooCommerce 网站。该活动的很多受害者都与食品和零售行业的大型企业相关。
我们发现的证据表明，该活动已持续活跃了几个星期，并且在某些案例中，其活跃时间甚至更长。令我们吃惊的是，该活动使用了我们以前未遇到过的一种更高明的隐藏技术。
新型活动
Magecart 攻击通常从利用目标网站中的漏洞或者感染这些网站所使用的第三方服务开始。在该活动中， 我们检测到的所有受害网站都是直接遭到利用，因为恶意代码段已注入到它们的某个第一方资源之中。
在某些情况下，该恶意代码段被插入到 HTML 页面中；而在其他情况中，该代码段则被隐藏在作为网站的一部分加载的某个第一方脚本内。
与很多其他 Magecart 活动一样，该活动的攻击基础架构包含三个主要部分：加载器、恶意攻击代码和数据外泄（图 1）。
加载器 ：简短、晦涩难懂的 JavaScript 代码段，负责加载攻击的完整恶意代码
恶意攻击代码 ：用于执行攻击的主要 JavaScript 代码；它会执行检测敏感输入、读取数据、中断结账流程和注入假表单等操作
数据外泄 ：用于将被盗数据传输给攻击者的命令和控制 (C2) 服务器的方法
为了更巧妙地隐藏攻击和加大检测难度，攻击者将攻击分为三个部分。这样，攻击的完整流程只会在专门针对的页面上激活；即，由于攻击者使用了这种混淆措施，因此完整攻击流程只会在攻击者希望它执行的地方激活。这会让攻击更加隐蔽，更难以被目标网站上可能采用的安全服务和外部扫描工具检测到。
虽然大多数 Magecart 活动在其流程和阶段上都具有相似之处，但两个活动的区别在于攻击者所采用的各种隐藏技术。这些技术用于遮掩攻击的基础架构，隐藏踪迹，并让检测和逆向工程变得复杂，最终延长攻击。
该活动的 3 种变化
我们发现该活动有三种变化，证明这一攻击在不断变化并且攻击者会随着时间推移进行改进，以避免此活动遭到检测和抵御：
前两种变化非常相似，唯一细微的区别在于加载器部分。
第三种变化则很特别，因为攻击者使用了网站的默认 404 错误页面来隐藏其恶意代码；这是一种我们以前从未见过的创新性隐藏技术。
我们来深入了解一下这一新型活动的三种变化的技术细节。
变化一
我们的威胁情报监控工具在某个大公司的网站上检测到一些可疑代码段，这引起了我们的注意，那时我们便开始了研究。对这些代码段进行分析后，我们发现它们是经过恶意编码的 JavaScript 加载器，仍然存在于该网站上并处于活跃状态。我们顺着此发现进行了深入调查，进而揭示了整个活动和其变化以及它对无数网站的影响。
变化一的加载器：冰山一角
该窃取器成功地将格式错误且具有 onerror 属性的 HTML 图片标签注入到被利用的网站中（图 2）。此属性包含一个经过混淆处理且进行 Base64 编码的恶意加载器代码段。该图片标签中有意留空的 src 属性旨在阻止网络请求并触发内嵌 onerror 回调的执行，该回调包含经过混淆处理的恶意 JavaScript 代码段。
将图片标签用于执行 JavaScript 代码是一种不常见但更复杂的技术。它可以帮助窃取器绕过安全措施，例如通常会分析网络流量的外部扫描器，而在这个特定案例中这些扫描器不会被触发。经过混淆处理的代码将在页面环境内执行，并伪装成页面自身所启动的原生第一方脚本运行。
图 2： 变化一的加载器：一个格式不正确的 HTML 图片标签，具有包含恶意加载器代码的 onerror 属性
已解码的加载器代码——运行时
经过混淆处理且进行 Base64 编码的代码在运行时执行后，它会转换为纯 JavaScript 并负责启动 WebSocket 通道（图 3）。此通道用作浏览器与攻击者的 C2 服务器之间的双向通信链路。
我们已经在近期的多个活动中观察到攻击者在 Magecart 攻击中使用 WebSocket。WebSocket 被视为一种更隐秘、更灵活的通信方法，让攻击者能够将单个网络通道用于各种用途。这包括在 C2 服务器与浏览器之间发送攻击的不同部分，以及在某些情境下促成数据外泄活动。
此代码值得注意的另一个方面是爬虫程序检测，即它会检查用户代理是否受自动控制。如果受自动控制，则该代码会终止其执行。这是一种聪明的反爬虫程序技术，旨在避开有可能检测到攻击的外部安全扫描器和沙盒。
图 3：变化一加载器的运行时解码的 JavaScript 代码
Websocket 通信流
建立 WebSocket 通道后，第一条消息是从攻击者的 C2 服务器发送到浏览器的。此消息以 Base64 编码字符串的形式进行传输，其中包含指示浏览器发回该页面的当前 URL 的一行 JavaScript 命令。
此步骤的目的在于，让 C2 服务器能够确定当前页面是结账（敏感）页面还是任何其他非结账页面。通过此方式，攻击者能够相应地调整后续步骤。
这种直观的服务器端验证让攻击者能够只在相关的目标页面上激活攻击，从而避免可能在非敏感页面上暴露。不过，这个示例也凸显出窃取器在想尽各种办法来避免被安全服务和外部扫描器检测到。
当 C2 服务器识别出结账页面 URL 时，该流程会继续执行下一个阶段。在此步骤中，另一条消息会被发送给浏览器。它是一个较长的 Base64 编码字符串，其中包含了完整的攻击代码。进行解码后，我们会看到一段经过混淆处理的冗长 JavaScript 代码（图 4）。
此代码负责在作为目标的敏感页面上执行各种恶意活动，其目的是读取用户的敏感个人数据和信用卡数据并将其传回窃取器的 C2 服务器。
经过混淆处理的后续数据外泄消息会从浏览器发送到 C2 服务器，其中包含了恶意代码收集的敏感被盗数据。正如先前所提到的那样，将同一 WebSocket 通道同时用于加载完整恶意代码和泄露被盗数据让整个过程更加隐秘，并且所涉及的网络请求数量比传统通信方法（如，XHR、fetch 或 HTML 资源请求）更少。
图 4：结账页面上的 WebSocket 流
变化二
变化二的加载器：换汤不换药
变化一和变化二之间的主要区别在加载器组件中。在变化二中，窃取器会插入一个内嵌脚本，其中包含的代码段与广为人知的 Facebook 访客活动跟踪服务 Meta Pixel 的代码段高度相似，但多出了几行代码（图 5）。
这些附加行是真正的加载器部分，而周围的 Meta Pixel 代码是误导性的烟幕弹，用于将其伪装成合法、不可疑的代码段。
此隐藏技术将恶意代码段伪装成 Google Tag Manager 或 Facebook 等广为人知的服务， 在近期的 Magecart 活动中广受欢迎。利用该技术，窃取器可以规避外部扫描器和研究人员对其进行静态分析。
图 5：变化二的加载器：伪装成 Meta Pixel 代码段的内嵌脚本，其中包含了恶意加载器
对图片的请求
当我们仔细检查伪造的 Meta Pixel 代码段内的可疑代码行后，发现它似乎会从网站自身的目录中获取一个 PNG 图片。该网络请求看起来像是对网站上所托管的正常图片的典型请求。但是，当我们查看此图片的实际内容时，很明显它并不像看上去那样无害（图 6）。
图 6：对攻击者已篡改并包含恶意代码的图片的网络图片请求
图片二进制数据内的恶意 JavaScript 代码段
该 PNG 图片的二进制数据包含一个附加在图片二进制文件末尾的 Base64 编码字符串（图 7）。加载器代码段随后会对此字符串进行提取、解码和执行（图 8）。解码后的字符串表示一个 JavaScript 代码段，该代码段与我们在变化一中加载器的 onerror 属性内找到的代码段完全相同。
该流程的后续步骤保持不变。此代码段会在运行时转换为纯 JavaScript 代码，该代码会启动连接攻击者的 C2 服务器的 WebSocket 通道，而攻击序列的剩余部分与先前所述内容相同。
图 7：包含隐藏恶意代码的图片的二进制数据
图 8：在解码后露出马脚的恶意代码，该代码最初以 Base64 编码并隐藏在图片中
变化三
现在我们来讨论一下最精彩的部分。虽然我们看到过类似的攻击，但此攻击很特别，着实令我们大吃一惊。
变化三的加载器：不能说一模一样，只能说完全不同
乍一看，此加载器类似于变化二中的加载器，但您会看到（和我们一样）它是完全不同的情况。在某些情况下，此加载器会伪装成 Meta Pixel 代码段，正如我们在变化二中看到的那样（图 9）。但是，在其他情况下，它会被注入到页面上的随机内嵌脚本中（图 10）。
对于此加载器，第一个值得注意的方面是对名为“icons”的相对路径的 fetch 请求。
图 9：变化三的加载器：恶意代码段，隐藏在伪装成 Meta Pixel 的代码段中
图 10：变化三的加载器：隐藏在任意内嵌脚本内的恶意代码段
404 错误？真的吗？
在加载器执行后，攻击会发送对 /icons的 fetch 请求，该路径是实际上不存在的相对路径。此请求会导致“404 Not Found”错误（图 11）。对响应中返回的 HTML 进行分析后，我们发现它看起来像是网站的默认 404 页面（图 12）。这很令人困惑，并且让我们想知道窃取器是否在我们所发现的受害网站上不再处于活跃状态。
图 11：由加载器发出的请求，该请求的目标是返回 404 错误的不存在路径
图 12：默认错误页面 HTML
永远不要低估加载器
我们回退一步并重新分析了该加载器，然后找到了拼图中所缺少的那一块。该加载器包含字符串“COOKIE_ANNOT”的正则表达式匹配，它会在 icons 请求中返回的 404 错误页面上执行。
于是，我们在所返回的 404 HTML 内搜索了该字符串，这就是问题所在！我们在包含“COOKIE_ANNOT”字符串的页面的结尾部分找到了一个隐藏的注释（图 14）。在此字符串旁边，连接着一个冗长的 Base64 编码字符串。这个已编码的字符串表示经过混淆处理的完整 JavaScript 攻击代码。该加载器会从注释中提取此字符串，对其进行解码，然后执行旨在窃取用户所输入的个人信息的攻击。
我们模拟了对不存在路径的附加请求，所有这些请求都返回了同一个 404 错误页面，其中包含携带已编码恶意代码的注释。 这些检查确认攻击者能够成功地更改整个网站的默认错误页面并将恶意代码隐藏在其中！
图 13：加载器变化 3：字符串“COOKIE_ANNOT”的正则表达式匹配。
图 14：经过恶意编码的注释，隐藏在错误页面 HTML 中
数据外泄
假表单
与变化一和二相比，攻击者在变化三中采用了一种不同的常见数据外泄技术，即注入假表单（图 15）。攻击者通常会在窃取器缺少对敏感输入的访问权限时利用此技术。
如果网站使用在第三方 iframe 或外部页面内实现付款表单的第三方支付服务时，就会出现这种情况。为了绕过此类情况，攻击者会创建一个与原始付款表单高度相似的假表单并覆盖前者， 这是一种更受欢迎的技术。以上便是变化三中被盗数据的外泄方式。
图 15：由恶意代码注入的假表单
当用户向攻击者的假表单提交数据时，页面上会显示错误，而假表单将隐藏起来，继而页面上会显示原始付款表单，并提示用户重新输入其付款详细信息（图 16）。
图 16：假表单已隐藏，并且用户被提示重新输入其信息
包含被盗数据的图片请求
提交假表单会向攻击者的 C2 服务器发出图片网络请求，该请求包含所有被盗的个人和信用卡信息，而这些信息以 Base64 编码字符串形式存放在查询参数中（图 17）。进行解码后，此字符串便显露出该请求的真正意图，而攻击的整个流程也清晰可见。
图 17：包含被盗数据的图片网络请求，这些数据以 Base64 编码字符串查询参数的形式包含在请求中
从变化三中学到的经验：404 情况
此隐藏技术具有高度创新性，我们在以前的 Magecart 活动中从未见到过。操纵目标网站的默认 404 错误页面这个想法会为 Magecart 攻击者带来各种创新选择，从而提高隐蔽和规避能力。
对于我们已确定的一些案例，在撰写本文时恶意加载器已经从受影响的网站页面中被移除。但是，默认 404 页面中的恶意注释仍然存在，有可能会让窃取器轻松地再次激活攻击。这凸显出检测此方法的复杂性以及相关抵御措施的重要性。
将对第一方路径的请求定向至 404 页面是另一种规避技术，它可以绕过内容安全策略标头以及可能会主动分析页面上的网络请求的其他安全措施。这毫无疑问成为了我们近期遇到的更为复杂的 Magecart 策略之一。
Akamai Client-Side Protection & Compliance 对阵窃取器
在研究此活动的过程中，我们针对 Akamai Client-Side Protection & Compliance模拟了此窃取器，该解决方案能够分析运行时 JavaScript 执行行为，以抵御 JavaScript 威胁和客户端攻击。
该解决方案成功地检测到这个复杂的窃取器并触发了高严重性事件进行即时抵御。在现实世界环境中，如果对特定网页启用了 Client-Side Protection & Compliance，那么网站所有者会收到图 18 所展示的告警，以便他们能够快速调查威胁并利用各种抵御选项实时做出响应。
图 18：Client-Side Protection & Compliance 在检测到窃取器后的模拟告警
结论
通过分析此活动，我们更深刻地认识到 Web 数据窃取技术正在不断地变化。它们变得更加复杂，导致通过静态分析和外部扫描进行检测和抵御变得更具挑战性。该领域的攻击者一直在寻找更好的方法，以将其攻击隐藏在受害者网站中，进而避开可能会监测到它们的各种安全措施。
本次研究中凸显出的复杂程度应当为各企业敲响警钟，必须时刻保持警惕并始终关注 Web 数据窃取攻击媒介，同时主动寻找新的先进方法来应对这些类型的攻击。
IOC
Pmdresearch[.]com
secures-tool[.]com
adsometric[.]com
cngresearch[.]com
