为 DGA 检测整合监督式和非监督式 Machine Learning

我们极为兴奋地推出首款监督式 ML 和安全集成方案！今天，我们将正式发布监督式 ML 解决方案包，旨在检测网络数据中的域名生成算法 (DGA) 活动。

除了配备经充分训练的检测模型以外，我们的版本还提供采集管道（ingest pipeline）配置、异常检测作业，以及有助于顺利轻松地完成从设置到 DGA 检测这一过程的检测规则。导航至检测规则库查看如何开始使用监督式 Machine Learning 来检测您网络中的 DGA 活动，并立即开始免费试用 Elastic 安全。 

DGA：分解

域名生成算法 (DGA) 是一种由众多恶意软件创建者所利用的技术，旨在确保避开防御措施而感染客户端机器。这一技术企图通过使用成百上千或成千上万随机生成的域名（最终解析为 C & C 服务器的 IP 地址）来隐藏受感染客户端机器与命令和控制（C & C 或 C2）服务器之间的通信。

为了便于以可视化的方式理解 DGA 攻击的过程，想象一下，你是战场上的一名士兵。像许多士兵一样，你拥有通过无线电频率进行通信的通信设备。你的敌人可能试图通过干扰你的无线电频率来干扰你的通信。应对这种情况的方法之一是采用跳频技术，即在传输过程中利用载波频率不断跳变的无线电系统。对敌人来说，频率变化似乎是随机且不可预测的，所以很难进行干扰。

DGA 就像是恶意软件的一个跳频通信信道。它们频繁更换域名，如此一来，通过 DNS 域名屏蔽来阻断恶意软件 C2 通信信道变得不可行。因为会有太多随机生成的 DNS 域名，因而难以试着识别并阻断它们。 

该技术早在 2009 年就在恶意软件领域强势登场，当时 “Conficker” 蠕虫开始使用大量随机生成的域名进行通信。安全研究人员团队通过关闭蠕虫用于通信的 DNS 域名来中断其 C2 信道，之后，蠕虫创建者开发了这一应对方案。在 2017 年 WannaCry 勒索软件席卷全球时，还执行了 DNS 缓解计划。

“鱼目混珠”

如果隐藏一棵树的最佳地点是森林，那么恶意软件运营商早就认识到，与正常的网络流量混在一起是躲过检测的最佳方法之一。带有随机生成域名的 HTTP 请求是网络安全监测和检测的一大难题。在现代网络中，HTTP 流量庞大，很难实现人工审查。一些恶意软件和机器人具有异常用户代理字符串，可使用搜索规则发出与其相关的警报，但恶意软件创建者可以很轻松地利用看起来与 Web 浏览器没什么区别的用户代理字符串。

随着移动网络和物联网的兴起，用户代理字符串数量变得如此庞大，以致于人工审查可疑活动也变得不可行。长期以来，Web 代理始终通过分类来查找已知可疑的 URL，但是 DGA 域名如此众多且“短寿”，使其通常未经分类。威胁情报可以识别与已知恶意软件家族和活动相关的 IP 地址和 HTTP 请求，但这些很容易被恶意软件运营商篡改，当我们对其进行搜索时，这些列表往往已经过时了。

众多组织收集的网络流量庞大，而且 DGA 生成的域名具有随机性，因此，基于规则的技术很难检测这种活动，而我们的监督式 Machine Learning 模型是不二之选！Elastic 的 DGA 检测 ML 模型采用推理，将在其被采集至 Elasticsearch 集群时检查 packetbeat DNS 数据，以自动确定哪些是潜在的恶意域名。按照下节中的步骤开始使用。 

开始使用

为了在安全应用程序中开始使用 DGA 检测，我们已向公开可用的规则存储库发布一组特性，以便将 Machine Learning 模型导入 Elastic Stack。这一存储库不仅为我们的社区提供了威胁检测的协作场地，而且还充当了共享测试和验证规则所需工具的场所。

请参阅我们之前的博文和网络研讨会了解更多该方案的相关信息。若您尚未订阅 Elastic Cloud，可通过 14 天免费云试用进行试用，开始体验监督式 ML 解决方案包以检测 DGA 活动

这个规则工具包的一部分是 CLI（命令行接口），既可用于测试规则，还可与堆栈进行交互。例如，我们已发布了各种 Python 库来与 Kibana API 进行交互。对于简化导入模型依赖项以使规则可操作的过程，这至关重要。若要开始扩充 DNS 数据并接收 DGA 活动的警报，请遵循以下三个步骤：

步骤一：导入模型

首先，必须将 DGA 模型、简单脚本和采集处理器导入堆栈。目前，DGA 模型及任何用于异常检测的非监督式模型（后续会有更多）均可以在采用 github 版本的检测规则库中可用。若要上传，运行下面的 CLI 命令：

python -m detection_rules es <args_or_config> experimental setup-dga-model -t <release-tag>

上传后，您将需要更新 packetbeat 配置，因为该模型将使用 DGA 评分扩充 packetbeat DNS 事件。这可通过在 Elasticsearch 输出配置中添加以下额外配置轻松实现：

output.elasticsearch:
  hosts: ["your-hostname:your-port"]
  pipeline: dns_enrich_pipeline

然后，监督式模型将分析并扩充 Packetbeat DNS 事件，其中包含以下 ECS 字段：

dns.question.name
dns.question.registered_domain

然后，模型将这些字段添加至已处理的 DNS 事件中：

扩充后的 DNS 数据的示例性截图如下所示：

注意：如需更多详情，请参阅检测规则自述文件。

关于 DGA 规则

现在，让我们来看看部分检测 DGA 活动并发出相关警报的条件搜索规则。解决方案包中提供两条搜索规则，可在 Elastic Security 应用程序的检测引擎中启用并运行：

1. Machine Learning Detected a DNS Request Predicted to be a DGA Domain
2. Machine Learning Detected a DNS Request With a High DGA Probability Score

第一条规则匹配任何 DGA 预测值为 1 的 DNS 事件，表明该 DNS 域名很可能是域名生成算法的结果，因此是可疑的。这里的规则仅用于查找以下条件：

event.category:network and network.protocol:dns and ml_is_dga.malicious_prediction:1

第二条规则匹配任何 DGA 概率评分超过 0.98 的 DNS 事件，表明该 DNS 域名很可能是域名生成算法的结果，因此是可疑的。这里的规则仅用于查找以下条件：

event.category:network and network.protocol:dns and ml_is_dga.malicious_probability > 0.98

与 Elastic 检测引擎中的所有规则一样，它们可以分叉（fork 打分支仓库），并根据局部特性进行定制。如果您发现另一个概率评分更适用于您的 DNS 事件，则可以向上或向下调整第二条规则中的概率评分。如果您希望提高警报队列中 DGA 检测的优先级，可以增加任何一条规则的风险评分。可将例外情况添加至规则中，以忽略误报情况，例如可能使用伪随机域名的内容分发网络 (CDN) 域名。

我们将要探讨的另一种未来可能性是使用事件查询语言 (EQL)，EQL 采用多变量相关性查找异常集群或基于搜索的警报集群。例如，如果我们发现参与可能的 DGA 活动的主机发来的警报集群，那么就更有信心检测到需要引起注意的重大恶意检测结果。

这一集群可以包含 DGA 警报及诸如罕见进程、网络进程、域名或 URL 等其他异常检测警报。这些额外的异常检测结果由 Elastic Security 应用程序中的 Machine Learning 方案包库生成。

步骤二：导入规则

DGA 方案包中的规则可使用检测规则 CLI（采用 .toml 格式）中的 Kibana 上传规则功能导入。由于检测规则库版本中提供的规则采用 .toml 格式，因此只需运行以下命令即可从规则库上传规则：

python -m detection_rules kibana upload-rule -h
Kibana client:
Options:
  --space TEXT Kibana space
  -kp, --kibana-password TEXT
  -ku, --kibana-user TEXT
  --cloud-id TEXT
  -k, --kibana-url TEXT
Usage: detection_rules kibana upload-rule [OPTIONS] TOML_FILES...
  Upload a list of rule .toml files to Kibana.
Options:
  -h, --help  Show this message and exit.
  -h, --help  Show this message and exit.

步骤三：启用规则并从中获益

由于我们已将经充分验证的监督式 ML 模型导入至堆栈、DNS 事件得到扩充且相关规则亦可供使用，那么，接下来仅需确认相关规则已启用并等待警报！ 

在检测引擎中查看该规则时，可确认该规则是否已激活，如下所示：

现在等待警报。警报生成后，您便可以通过时间线功能来调查 DNS 事件并着手展开相关调查。

然而，Machine Learning 模型都并非无懈可击！有些良性域名将被错误地标记，我们称之为误报。在下一节中，我们将探究如何利用预先配置的异常检测任务及这一版本附带的相关规则来排除误报。

误报？采用异常检测补救措施！

与每一种检测技术一样，总会有一些误报情况。这些误报可能会以 CDN 流量或自定义域名的形式出现，看起来是恶意域名，但实际上在该环境中是正常的。为了确保 DGA 检测能够适用每个用户环境，我们已创建预先配置的命名为 experimental-high-sum-dga-probability 的异常检测任务。启用后，这一 ML 任务会检查监督式 DGA 模型生成的 DGA 评分（没错，就是 LM 的作用），并为特定源 IP 地址寻找评分异常高的异常模式。此等事件会被分配异常评分。

为了最大限度地从异常检测任务中获益，我们将同时发布补充规则：Potential DGA Activity。这将在安全应用程序的检测页面中创建基于异常的警报。

预先配置的异常检测任务和补充规则在我们的检测规则库版本中均可用。 

如何选择适合您所在环境的正确配置

首先从监督式 DGA 模型开始。该模型对通过 Packetbeat 采集的每个 DNS 请求进行分析，并分配一个表明该请求中涉及的域名很可能存在恶意的概率。您可以使用“开始使用（Get started）”一节讨论的条件逻辑规则在安全应用程序中直接使用监督式模型的输出，或者，也可以导入并启用预先配置的异常检测任务和规则，以便根据所处环境的微妙之处自定义检测任务。 

如何选择适合您所在环境的正确配置？从简单配置开始。启用“开始使用”一节中的条件搜索规则。这些规则直接作用于监督式模型的输出，并将快速帮助了解所处环境中有多少误报背景噪声。如果您发现监督式模型的直接输出上运行的条件搜索规则产生太多警报，则可能会从导入和启用异常检测任务中受益。 

尤其是，在异常检测任务结果上运行的 ML 检测规则可能有助于寻找聚合有大量 DGA 活动的来源（而非针对单个 DGA 评分逐个发出警报）。如果您没有运行中的 ML 模块，启动免费试用版，或者可以在 Elastic Cloud 中试用。

异常检测模型的示例性截图及版本随附的相关规则如下所示：

案例研究：检测 SUNBURST 攻击中的真实 DGA 活动

让我们尝试将这一实验性 DGA 工作流应用至最近发生的 SUNBURST 攻击活动中。 

概括来说，12 月 13 日太阳风公司 (SolarWinds) 针对猎户座 (Orion) 网络管理平台遭受供应链攻击发布了安全建议。撰写本文时，这一攻击影响到 2020 年 3 月至 6 月发布的猎户座版本。同样，12 月 13 日，火眼公司 (FireEye) 发布了一则有关全球性攻击活动的消息，涉及影响到猎户座软件部分版本的太阳风供应链折衷方案。

我们此前发表了一篇博文，探讨 Elastic 用户及太阳风案例，通常称为 SUNBURST。这篇文章强调了 Elastic Endgame 和 Elastic Endpoint Security 所采用的 Elastic Security 恶意软件预防技术已针对太阳风信息披露中所述的攻击检测进行更新。

作为一种复杂的软件供应链攻击行为，SUNBURST 将恶意软件植入太阳风公司的猎户座产品中，并利用自动更新机制分发。撰写本文时，该事件的波及规模、影响范围和影响程度仍在评估中。 

现有 Elastic Security 检测

一名安全研究员共享了SUNBURST 恶意软件所用的一组 1,722 个 DGA 生成的域名。DNS Tunneling 是现有的基于 Elastic Security Machine Learning 的检测规则之一，在本示例中的 DNS 域名上生成两个基于异常的警报。与 DNS Tunneling 类似，SUNBURST 域名样本中的子域-父域比例非常高。对与本规则相关联的 ML 任务进行编码以分析 Packetbeat 数据，但可以对其进行复制和修改，进而以 Elastic Common Schema (ECS) 格式采集其他 DNS 事件。这便是 DNS Tunneling ML 任务：

该 ML 任务具有一个名为 DNS Tunneling的关联检测规则：

通过此等 Elastic Security 规则，这些异常检测（如下所示）可转换为检测警报和可选通知，以便将其归入适当的事件分类和响应工作队列中。这便是 SUNBURST 异常检测在 Elastic Machine Learning 应用程序中的呈现方式：

这一检测十分有用，但可能不会检测到所有 DGA 活动。为了增强 DGA 检测功能，我们将推出实验性 DGA 检测工作流。

使用实验性 DGA 工作流

我们发现，实验性 DGA ML 检测工作流可检测大部分的此类活动。我们通过本文探讨的监督式 DGA 检测模型运行了 SUNBURST DGA 域名（参见上述内容，了解“如何下载并运行该模型及其规则”的相关详情）。我们发现，该模型将样本中的 82% 的域名标记为 DGA，这将在样本集中生成 1,420 个警报。以下是一个由监督式模型标记为 DGA 活动的 SUNBURST DNS 域名的截图：

这些事件可以转化为使用检测规则Machine Learning 检测到预测为 DGA 域名的 DNS 请求的检测警报。此外，我们也可以复制该规则并对其进行修改，以匹配观察到的诸如 SUNBURST 等特定恶意软件实例所使用的父域。我们可以通过向规则查询添加测试来匹配这组 SUNBURST DGA 事件，如下所示：

network.protocol:dns and ml_is_dga.malicious_prediction: 1 and dns.question.registered_domain: "avsvmcloud.com"

然后，我们可以为该规则指定一个临界严重性级别和一个 99 分的高风险评分，以便将其移动至警报和分析工作队列的前面。以下是该规则所生成的警报截图，对其进行修改后，可提醒检测 SUNBURST DGA 活动：

我们已在解决方案包中纳入该规则，Machine Learning 检测到使用已知 SUNBURST DNS 域名的 DGA 活动。在实际感染情况下，采用高频 DGA 的恶意软件实例可能生成足够多的警报，以触发默认设定值为 100 的 max_signals 断路器。在这种情况下，我们可能会对一些恶意软件实例（而非其他实例）发出警报，具体取决于搜索中最先匹配到的事件。 

为了确保识别更多参与 DGA 活动的受感染的主机，我们将 DGA 搜索规则中的 max_signals 值增加到 10,000。注意：此设置不能在规则编辑器中修改，而必须在外部规则文件中修改，然后将其导入。该设置可通过在编辑器中查阅规则文件来查看。

在 DGA 活动繁多且警报众多的情况下，我们还可以聚合并筛选 DGA 警报或事件，以便在数据表中通过主机名或源 IP 进行计数，如下所示：

此外，我们还将为 Packetbeat DGA 事件提供一个带有可视化和聚合功能的示例仪表板，包括按照 source.ip 聚合的数据表可视化功能。或者，如果 DNS 事件包含该字段，也可以按照 host.name 进行聚合。该文件名为 dga-dashboard.ndjson，可通过选中 Saved Objects（保存的对象）页面上的 Import（导入）将其导入至 Kibana，该页面将在选中 Stack Management（堆栈管理）后显示。

以下是该仪表板在 packetbeat-* 索引中显示 DGA 事件的截图：

我们随时为您提供真诚帮助

我们随时待命！若在此过程中遇到任何问题或想要了解更多关于威胁检测和 Machine Learning 的基本原理，请通过我们的社区 Slack 渠道、我们的讨论论坛与我们取得联系，或者与我们面对面针对我们公开的检测库展开合作。感谢您的关注！祝您生活愉快！