越来越多的攻击由多个独立的执行文件或脚本组成。高级攻击者技术（如 “living off the land” (LotL)）在单独观察时看起来是正常的，但在父子上下文中观察时会变得更加可疑。如果在您的环境中运行 Windows，则必须有一个系统来检测这些类型的攻击。传统的基于启发式的检测虽然在检测单个事件方面有效，但通常无法在多步骤攻击中进行概括。在 Elastic，我们训练了一个 Living off the Land 分类器、异常检测作业和安全检测规则，以帮助我们的安全专业人员发现 LotL 攻击。
随着 Elastic Stack 中集成包的出现，我们现在可以提供完整的、可自定义的包，其中包括 LotL 分类模型、异常检测作业配置、检测规则和推理管道，从而可以更轻松地安装和启动整个端到端数据管道，从收集 Windows 事件到潜在 Lotl 攻击的警报。我们将引导您完成设置过程，以便您可以自己尝试。
ProblemChild：回顾
在之前的博客文章中，我们讨论了如何使用检测规则存储库命令行界面 (CLI) 来设置 ProblemChild 框架并在您的环境中启动并运行。我们现在在 Kibana 的 Integrations 应用程序中添加了一个Living off the land (LotL) 检测包。只需单击一下，即可安装并开始使用 ProblemChild 模型以及相关资产，包括异常检测配置和检测规则。
如之前的博客中所述，ProblemChild 是一个使用 Elastic Stack 构建的框架，用于检测 LotL 活动。LotL 攻击通常难以检测，因为攻击者会利用目标环境中已存在的看似无害的软件来逃避检测。在正在进行的攻击事件中，环境中产生的进程谱系可以提供强烈的信号。
ProblemChild 的监督机器学习 (ML) 组件利用 Windows 进程事件元数据中存在的进程谱系信息，使用推理在摄取时将事件分类为恶意或良性。然后，应用异常检测来检测监督模型检测为恶意的事件中的罕见进程。最后，检测规则会针对罕见的父子进程活动发出警报，表明存在 LotL 攻击。
组织中看到的事件的巨大数量和种类对使用规则和启发式方法检测 LotL 攻击提出了挑战，这使得像 ProblemChild 这样的基于 ML 的框架成为一个很好的解决方案。
入门
自 8.0 起，我们已将模型和相关资产（包括管道、异常检测配置和检测规则）发布到 Kibana 的 Integrations 应用程序中。我们将继续保持这种格式。
如果您没有 Elastic Cloud 集群，但想开始尝试发布的 ProblemChild 包，您可以开始 Elastic Cloud 的14 天免费试用。
现在，我们将了解如何使用发布的 Living off the land (LotL) 检测包在几分钟内让 ProblemChild 在您的环境中启动并运行。
步骤 1：安装包资产
在 Kibana 中，Integrations 应用程序现在包含 LotL 攻击检测包。要安装资产，请在设置选项卡下单击安装 LotL 攻击检测资产按钮。
这将安装使用 ProblemChild 模型在您的环境中检测到 LotL 活动时生成警报所需的所有构件。
安装完成后，您可以导航到 Stack Management > Ingest Pipelines，并看到已安装 <版本号>-problem\_child\_ingest\_pipeline，现在可用于丰富传入的摄取数据。摄取管道利用 <版本号>-problem\_child\_inference\_pipeline 来执行此操作。
同样，现在可以在 Machine Learning > Model Management > Trained Models 中看到安装的 ProblemChild 模型
步骤 2：丰富您的数据
现在，您可以使用摄取管道来摄取您的数据了。这将使用机器学习模型的预测来丰富传入的数据。
此管道旨在与 Windows 进程事件数据（例如Winlogbeat 数据）一起使用。您可以通过添加简单的配置设置来将安装的摄取管道添加到 Elastic beat。
如果您的索引已关联了摄取管道，则可以使用管道处理器将 ProblemChild 摄取管道集成到您现有的管道中。
您还需要将以下映射添加到您选择的 Elastic beat
{
"properties": {
"problemchild": {
"properties": {
"prediction": {
"type": "long"
},
"prediction_probability": {
"type": "float"
}
}
},
"blocklist_label": {
"type": "long"
}
}
}您可以在 Stack Management > Index Management > Component Templates 下执行此操作。可以编辑以添加自定义组件的模板将标记为 @custom 后缀。通过将上面的 JSON blob 粘贴到 Load JSON 弹出窗口中，编辑您的 Elastic beat 的 @custom 组件模板。
现在，您应该看到该模型使用以下字段丰富了传入的 Windows 进程事件
problemchild.prediction
- 值为 1 表示该事件预计为恶意，值为 “0” 表示该事件预计为良性。
prediction_probability
- 一个介于 0 和 1 之间的值，表示模型对其预测的置信度。值越高，置信度越高。
blocklist_label
- 值为 1 表示该事件是恶意的，因为命令行参数中的一个或多个术语与黑名单匹配。
如果您想要立即测试摄取管道是否按预期使用您的数据，则可以使用一些带有模拟管道 API的示例文档，并确认您看到了 problemchild 字段。
步骤 3：运行异常检测
该包包括多个预配置的异常检测作业。这些作业使您能够在监督模型检测为恶意的事件中找到最罕见的事件，以便确定哪些事件需要您的分析师立即关注。
要在丰富的数据上运行这些作业，请转到 Machine Learning > Anomaly Detection。当您使用作业向导创建作业时，您应该看到一个选项“使用带有 LotL Attacks 卡片的预配置作业”。选择该卡片后，您将看到可以运行的多个预配置的异常检测作业。请注意，这些作业仅对已由摄取管道丰富的索引有用。
步骤 4：启用规则
为了最大限度地发挥 ProblemChild 框架的优势，请激活安装的检测规则。当满足监督模型或异常检测作业的某些条件时，会触发它们。可以在包本身的概述页面或最新的实验检测版本中找到已安装规则的完整列表。
为了启用和使用已安装的规则，您可以导航至安全 > 规则，然后选择_加载 Elastic 预构建规则和时间线模板_。
请注意，其中既有搜索规则，也有 ML 作业规则。搜索规则由监督模型触发，例如以下规则：
以上规则匹配任何 Windows 进程事件，其中监督模型或其阻止列表的预测值为 1（恶意）。
ML 作业规则由您在步骤 3 中设置的异常检测作业发现的异常触发，例如以下规则：
以上规则在每次异常检测作业 problem_child_rare_process_by_host 检测到异常得分大于或等于 75 的异常时触发。
摘要
正如第一篇博文中提到的，ProblemChild 的监督 ML 组件经过训练，可以预测在可用于 LotL 攻击的进程或命令行参数上的值为 1（恶意）。这并不意味着监督模型预测为值 1 的所有内容都表示 LotL 活动。预测值 1 应更解释为“这可能是潜在的恶意行为”，而不是“这肯定是 LotL 活动”。
ProblemChild 的真正优势在于异常检测，它会在监督模型标记为可疑的事件中浮现出罕见的父子进程关系。这不仅有助于减少误报的数量，还有助于安全分析师专注于更小、更有针对性的列表进行分类。
当然，您可以从搜索规则开始，这将直接根据监督模型的结果发出警报。如果这些规则产生的警报数量可管理，并且您有时间和资源深入研究这些警报，则可能不需要启用异常检测作业。但是，如果您随后注意到这些规则产生过多的警报（这通常在大多数大型组织中都是如此），那么您可能会受益于启用异常检测作业及其相应的规则。
联系我们
我们希望您尝试 ProblemChild，并在我们努力为其添加新功能时给我们反馈。如果您在此过程中遇到任何问题，请通过我们的社区 Slack 频道、讨论论坛或我们的开放检测存储库联系我们。
您始终可以在 Elastic Cloud 上体验最新版本的 Elasticsearch Service，并按照此博客在您的环境中为您的 Windows 进程事件数据设置 ProblemChild 框架。并利用我们的快速入门培训为您的成功做好准备。祝您实验愉快！