前言
作为本系列关于 Google Workspace (GW) 攻击面文章的延续，我们将不再关注攻击面的调查，而是专注于使用 Elastic 设置威胁检测实验室。在第一部分中，我们探讨了 GW 的重要资源和功能，同时追踪了攻击者可能利用的入侵技术。在第二部分中，我们将为您提供开始研究针对 GW 的威胁所需的基石，并提供使用 Elastic 技术检测这些威胁的资源。在提供的步骤中使用的信息应调整为适合您自己的实验室和测试环境。如果您觉得不需要设置自己的实验室，也没关系，因为这其中包含了展示我们如何检测 GW 威胁的示例。
接下来是本系列的第三部分，我们将通过模拟 GW 环境和模拟威胁活动来涵盖常见的入侵技术。这样做，我们将构建检测逻辑，以进一步检测几种常见的技术。
Elastic 资源将免费提供，但 GW 的注册域名是必要的，并且将在接下来的步骤中介绍，这纯粹是为了最大程度地保证真实性。实验室的搭建时间大约为 20-30 分钟。
快速了解
对于那些可能不熟悉 Elastic 当前技术栈的用户：请花几分钟时间回顾一下它提供的当前解决方案。简而言之，该技术栈是一个全方位的产品，可以从单个界面部署到任何地方！如果您想探索有关 Elastic 安全解决方案的更多信息，文档 是一个很好的起点。
在本文中，我们将重点关注安全解决方案，其中包括一个强大的检测引擎和 600 多条预构建的威胁检测规则、一个可以部署到 Windows、Linux 或 macOS 端点并从各种本地和云环境收集数据的端点代理，以及实时检测和阻止威胁。更不用说，这种端点行为逻辑也全部公开在我们的防护工件存储库中。
我们的端点代理协调器，Fleet，可以在 Elastic Stack 的 Kibana 界面中进行管理。Fleet 允许我们设置并将安全策略部署到我们的端点代理。由于支持的集成列表非常广泛，因此这些策略具有极强的可定制性。
可以将集成视为 Elastic Agent 的一个模块，该模块提供处理器来收集特定数据。当添加到我们的安全策略时，集成允许 Elastic Agent 摄取日志、应用我们的 Elastic 通用架构 (ECS) 并将它们存储在 Elastic Stack 中以进行搜索或触发警报。如果您对 Elastic 的特定集成感兴趣，可以在这里搜索！
有了这些信息，您几乎可以假设 Elastic Stack 允许您仅用一个信息技术 (IT) 人员来管理所有这些内容。
无论如何，我们的目标是为Google Workspace创建一个威胁检测实验室，如该图所示
设置过程非常简单。请注意，您的环境不必以云为中心；如果您希望在本地执行所有操作，也完全可以。 Elastic 容器项目 是本地 Docker 构建技术栈的一个很好的资源。
注册 Google Workspace
为了使用 GW，您必须拥有一个注册的 Google 帐户电子邮件地址和组织。如果您已经为某个组织设置了 GW，请登录管理控制台并继续在 Google Cloud 中创建项目。此过程不会详细介绍如何创建 Google 帐户。
创建完成后，请执行以下操作
- 访问https://workspace.google.com > 立即开始
- 填写后续步骤中请求的信息
- 公司名称：DeJesus 考古
- 员工人数：2-9 人
- 地区：美国
对于此实验室，我们将使用 DeJesus 考古作为公司名称，因为它朗朗上口（当然，谁小时候不想当考古学家呢？）。当然，我们将从这些日志中挖掘出比从地球上挖掘出的更近期的证据。
最终，系统会询问您“您的企业是否有域名？”。GW 要求您拥有自己的域名才能使用其服务，特别是组织的管理控制台。今天，我们将选择“否，我需要一个”，并将使用 dejesusarcheology.com，但请您选择或使用您自己的域名。从这里，您需要输入其他企业信息来注册您的域名和组织。
您需要一个用户名才能登录您的 GW 帐户并创建您的企业电子邮件地址。我们将使用[email protected] 作为管理电子邮件。完成后，请使用您的新电子邮件登录您的 GW 管理控制台，您应该会看到如下所示的类似界面。
设置 Google Cloud Platform (GCP)
为了让 Elastic 代理摄取 GW 日志，它完全依赖于向Reports API发出请求，因此，我们需要利用 GCP 来获取托管服务帐户。此服务帐户的凭据将由我们的 Elastic 代理使用，然后利用管理 SDK API 从 GW 的 Reports API 中提取日志到 Elastic Stack 中。域范围委托和 OAuth2 对于身份验证和资源访问非常重要，但将在后面的步骤中启用。
创建项目
GCP 是分层的，因此我们必须首先创建一个项目。如果您已经设置了 GCP 环境，我们建议创建一个新项目，该项目通过注册的域名链接到您的 GW，方法如下所示。
完成以下步骤
- 使用用于设置 GW 的同一个 Google 帐户登录Google Cloud
- 选择以下内容：选择项目 > 新建项目
- 输入后续步骤中描述的信息
- 项目名称：dejesus-archeology
- 组织：dejesusarcheology.com
- 位置：dejesusarcheology.com
完成后，您应该在 GCP 中拥有一个新的组织和项目。默认情况下，只有项目的创建者有权管理该项目。
启用 Admin SDK API
我们的 Elastic 代理最终将使用我们的 GCP 服务帐户，该帐户使用Workspace Admin SDK与 GW 管理控制台 REST API 进行交互，因此需要在 GCP 中启用它。为了让您安心，我们只会为此管理 SDK 启用对 Reports API 的读取访问权限。
完成以下步骤
- 选择 Google Cloud 导航菜单 > API 和服务 > 已启用 API 和服务
- 在 API 库页面搜索并启用“Admin SDK API”
完成后，您将在您的项目中启用 Admin SDK API，您的服务帐户将能够从中提取数据。
配置 OAuth 同意屏幕
接下来，我们需要为我们的服务帐户和应用程序设置OAuth 同意屏幕，当它们向 GW 创建 API 请求时，因为它将包含必要的授权令牌。
完成以下步骤
- 选择 Google Cloud 导航菜单 > API 和服务 > 已启用的 API 和服务 > OAuth 同意屏幕
- 用户类型 > 内部 > 创建
- 在后续步骤中填写以下信息
- 应用名称：elastic-agent
- 用户支持邮箱：[email protected]
- 授权域名：dejesusarcheology.com
- 开发者联系信息：[email protected]
- 保存并继续
- 保存并继续
- 返回仪表板
完成后，我们将拥有一个使用 OAuth 2.0 进行授权的注册应用程序，以及已设置的同意屏幕信息。请注意，此应用程序每天的默认令牌请求限制为 10,000，但可以增加。我们建议将您的 Elastic 代理的拉取速率设置为每 10 分钟，这应该不会接近达到此阈值。设置代理的拉取速率将在后面的步骤中进行。
创建服务帐户
为了让 Elastic 代理从 GW 中提取数据，我们需要为代理创建一个服务帐户。此帐户适用于非人类应用程序，允许它通过我们之前启用的 Admin SDK API 访问 GW 中的资源。
要创建服务帐户，请执行以下操作
- 选择 Google Cloud 中的导航菜单 > API 和服务 > 凭据 > 创建凭据 > 服务帐户
- 输入以下信息
- 服务帐户名称：elastic-agent
- 服务帐户 ID：elastic-agent
- 其余部分留空并继续
- 选择您的新服务帐户 > 密钥 > 添加密钥 > 创建新密钥 > JSON
默认情况下，基于项目的继承，将向此服务帐户应用所有者角色，您可以根据需要缩小权限范围。完成后，您应该拥有一个名为 elastic-agent 的服务帐户，以及保存在主机上的 JSON 文件中此服务帐户的凭据。我们将在 Fleet 策略集成设置期间输入此信息。
启用域范围委托
我们的服务帐户将需要域范围委托权限才能访问超出 GCP 并进入 GW 的 API。为此必要的重要数据已在之前的步骤中建立，我们需要 API 密钥、服务帐户和 OAuth 客户端 ID。
要为您的服务帐户启用域范围委托，请执行以下操作
- 在您的 GW 管理控制台中选择 > 导航菜单 > 安全 > 访问和数据控制 > API 控制
- 选择管理域范围委托 > 添加新
- 客户端 ID：来自 GCP 中服务帐户的 OAuth ID
- Google Cloud Console > IAM 和管理员 > 服务帐户 > OAuth 2 客户端 ID（复制到剪贴板）
- OAuth 范围：https://www.googleapis.com/auth/admin.reports.audit.readonly
我们 GCP 中的服务帐户只需要访问 admin.reports.audit.readonly 才能访问 GW 审计报告，这些报告将转换为 Elastic Stack 的 ECS 文档。
如果您走到这一步，恭喜您，您做得非常出色！您的 GW 和 GCP 环境现已设置并完成。此时您几乎完成了，我们只需要设置 Elastic Stack。
设置您的免费云堆栈
对于此实验，我们将使用免费试用的云弹性，您可以使用您首选的 Google 或 Microsoft 邮箱帐户。您还可以选择在Amazon Web Services (AWS)、GCP 或Microsoft Azure中创建堆栈，如果您想在现有的云服务提供商 (CSP) 中启动您的堆栈。免费试用版将把堆栈部署到 GCP。
注册免费试用后，我们可以专注于配置 Elastic Stack 部署。对于此实验，我们将调用我们的部署 gw-threat-detection 并将其部署在 GCP 中。您可以保留部署的默认设置，我们建议使用最新版本以获取所有最新功能。出于演示目的，我们使用以下内容
- 名称：gw-threat-detection
- 云提供商：Google Cloud
- 区域：爱荷华州 (us-central1)
- 硬件配置文件：存储优化
- 版本：8.4.1（最新）
设置完成后，选择“创建部署”，Elastic Stack 将自动部署到 GCP，并将显示您的部署凭据。您可以将这些凭据下载为 CSV 文件或将它们保存在您认为最合适的位置，但它们对于登录已部署的堆栈至关重要。部署大约需要 ~5 分钟才能完成，完成后，您可以选择“继续”登录。恭喜，您已在几分钟内成功部署了 Elastic Stack！
从安全解决方案设置 Fleet
提醒一下，Fleet 支持创建安全策略，该策略可以合并GW 集成到弹性代理中，以便访问并将 GW 日志提取到我们的堆栈中。
创建 Google Workspace 策略
为了让我们的 Elastic 代理知道它正在使用哪个集成，收集哪些数据以及在我们的堆栈中将这些数据流式传输到哪里，我们必须首先设置一个自定义 Fleet 策略，名为 Google Workspace。
要在您的 Elastic Stack 中设置 Fleet 策略，请在您的 Elastic Stack 中执行以下操作
- 导航菜单 > 管理 > Fleet > 代理策略 > 创建代理策略
- 输入“Google Workspace”作为名称 > 创建代理策略
在端点上安装 Elastic 代理
如前所述，我们必须在端点上安装至少一个代理才能访问 GW 中的数据，并且将受已部署的 GW 策略约束。我们建议使用轻量级 Linux 主机，无论是本地虚拟机还是 GCP 等 CSP 中的虚拟机，以使所有内容都位于同一环境中。我将在 Google 的 Compute Engine (GCE) 中使用Ubuntu 20.04 LTS VM 实例，该实例与我们一直在使用的 GCP 项目相同。您的端点可以是轻量级的，例如 GCP N1 或 E2 系列，因为它的唯一目的是运行 Elastic 代理。
设置好端点后，请在您的 Elastic Stack 中执行以下操作以部署您的代理
- 导航菜单 > 管理 > Fleet > 代理 > 添加代理
- 确保选择了 GW 策略
- 选择合适的操作系统
- 选择剪贴板图标以复制命令
- 在您的端点上运行命令以安装代理
- 完成后，Fleet 应显示一个复选标记并显示已注册 1 个代理且已确认传入数据
将 Google Workspace 集成分配给 Fleet 策略
我们必须将 GW 集成添加到我们的 GW 策略中，以便它可以从 GW 收集数据并将其流式传输到我们的 Elastic Stack。我们将配置 GW 集成设置，以便在设置 GW 环境时创建信息，以避免在我们的 Ubuntu 主机上出现不安全的凭据。
⚠️ GW 集成的默认间隔为 2 小时，这意味着 Elastic 代理将每 2 小时检索一次数据，因为存在潜在的数据保留和延迟时间。这应该在集成本身中进行调整，并在以下步骤中在您的 Elastic Stack 中进行说明
- 导航菜单 > Fleet > 代理策略 > Google Workspace > 添加集成
- 搜索“Google Workspace”> 选择 Google Workspace
- 选择“添加 Google Workspace”
- 为此集成输入以下信息
- 集成名称：google workspace
- Jwt 文件：复制服务帐户创建步骤中 JSON 文件的内容
- 委托帐户：[email protected]（使用您自己的）
- 间隔：10m
- 代理策略：Google Workspace
- 选择“保存并继续”
- 选择“保存并部署更改”
完成后，您的 GW 集成应分配给您的 GW 策略，并且一个代理分配了此策略。
回顾一下我们迄今为止的 Elastic Stack 设置，我们已完成以下操作
- 部署了 Elastic Stack
- 创建了 Fleet 策略
- 设置了一个轻量级 Linux 端点
- 将 Elastic 代理部署到 Linux 端点
- 在我们的 Fleet 策略中启用了 Google Workspace 集成
将 Google Workspace 集成分配给 Fleet 策略
与其依赖检测工程 (DE) 的更高权限，不如花点时间实际确认 GW 数据是否按预期被提取到我们的堆栈中。我们可以依靠 Elastic Stack 的发现功能，该功能允许我们在现有 ECS 文档中搜索特定条件。为此，我们将使用过滤器条件data_stream.dataset : "google_workspace.*"来查找源自 Google Workspace 数据流的任何 ECS 文档。
如果您没有任何结果，请在您的 GW 中生成一些活动，例如创建新用户、启用电子邮件路由、创建新的组织单位 (OU) 等，然后在 10 分钟窗口过去后刷新此查询。
如果找到结果，那么恭喜您，因为您现在拥有一个功能齐全的 Google Workspace 威胁检测实验室，以及用于 SIEM 的 Elastic Security！
启用 Google Workspace 检测规则
如前所述，Elastic 拥有 600 多个预构建的检测规则，不仅适用于 Windows、Linux 和 MacOS 端点，还适用于包括 GW 在内的多个集成。您可以查看我们当前现有的 GW 规则和 MITRE ATT&CK 覆盖范围。
要启用 GW 规则，请在 Elastic Stack 中完成以下操作
- 导航菜单 > 安全 > 管理 > 规则
- 选择“加载 Elastic 预构建规则和时间线模板”
- 所有规则加载完成后
- 选择“标签”下拉菜单
- 搜索“Google Workspace”
- 选择所有规则 > 构建操作下拉菜单 > 启用
虽然我们不会深入探讨所有规则信息，但我们建议您这样做。Elastic 提供了一些其他信息，例如相关集成、调查指南等！此外，您可以通过创建您自己的检测规则（使用“创建新规则”按钮）并贡献到我们的检测规则存储库来回馈社区。
让我们触发一个预构建规则
在此示例中，我们将激发Google Workspace 自定义管理员角色已创建检测规则。在我们的 GW 管理控制台中，访问帐户 > 管理员角色并使用以下信息创建新角色
- 名称：管理员
- 描述：您的选择
- 管理控制台权限
- 警报中心：完全访问
现在，我们不完全确定为什么管理员角色可以访问我们的警报中心，但该角色似乎范围界定不当，或者有人希望能够在我们的安全团队调查之前可能静默一些警报。虽然创建管理帐户（T1136.003）并不罕见，但如果出现意外情况，应始终对其进行调查，以确保云角色（T1098.003）的范围界定正确。
要查看我们的检测警报，在您的 Elastic Stack 中，访问导航菜单 > 安全 > 警报，以下内容应显示您的警报。由此，我们可以看到我们的规则触发了，以及 通过域范围授权委托授予 Google Workspace API 访问权限。
如果我们从操作列中选择“查看详细信息”，我们会收到一个弹出面板，其中显示警报概述、来自我们的 ECS 文档的表格数据字段和值，以及原始 JSON。
大多数 GW 检测规则都可以使用一些一致的字段开发，例如我们在我们的 文档 中描述的那些字段，从而使新规则更容易创建。如果您想查看 ECS 模式包含的所有 GW 数据字段，可以在 此处 找到这些信息。
让我们触发自定义规则
虽然预构建的检测规则非常适合在入职期间提供威胁覆盖，但您可能希望搜索您的数据并创建适合您环境的新自定义规则。
由于 Elastic Stack 捆绑了额外的搜索功能，因此我们可以依靠 Analytics Discover 功能来开始搜索我们的原始数据以查找与 GW 相关的文档，方法是访问导航菜单 > 分析 > Discover。
在这里，我们可以将数据视图更改为 logs-*，然后对 event.dataset: google_workspace* 执行开放式 KQL 查询，这将返回所有源自 GW 的文档。然后，您可以根据可用字段开始对数据进行制表，或查看每个文档的详细信息。
了解这一点非常重要，因为它会影响规则开发。规则通常被设计为数据缩减练习，从非常广泛开始，并随着时间的推移逐渐细化成有效的规则。如果您在进行此练习后在创建检测逻辑方面遇到困难，我们关于如何执行此操作的 理念 可能会有所帮助。
首先，我们将向我们的组织添加一个用户 Ray Arnold，他拥有管理访问权限。使用我们的 Ray Arnold 帐户，我们将在 GW 中生成一些可疑事件，例如为 Gmail 创建自定义电子邮件路由，将发送到我们的主要管理员（Terrance）的电子邮件转发到 Ray Arnold。在这种情况下，我们专注于通过电子邮件转发规则（T1114.003）潜在收集敏感信息。
完成以下步骤
- 添加 Ray Arnold 作为用户
- 导航到 GW 中的用户设置
- 选择“添加新用户”
- 名字：Ray
- 姓氏：Arnold
- 选择“添加新用户”
- 添加工程师组并使 Ray Arnold 成为所有者
- 导航到 GW 中的组设置
您可以配置以下设置，例如这些示例
- 组名称：工程师
- 组电子邮件：[email protected]
- 组描述：恐龙公园的工程组，负责技术和喂养迅猛龙。
- 组所有者：[email protected]
- 标签：邮件和安全
- 谁可以加入该组：仅受邀用户
- 选择“创建组”
现在我们将管理员角色和权限分配给 Ray Arnold：1. 导航到 Ray Arnold 的用户帐户 2. 选择“管理员角色和权限” > 分配角色 3. 超级管理员 -> 已分配 4. 组管理员 -> 已分配 5. 服务管理员 -> 已分配 6. 选择“保存”
如果操作正确，Ray Arnold 应该是 DeJesus 考古组织中 GW 的新用户。他也是工程师组的所有者，并且已将超级管理员、组管理员和服务管理员角色分配到其帐户。接下来，我们需要使用 Ray Arnold 的帐户登录 GW 管理控制台并添加自定义电子邮件路由。
这为我们的组织提供了一个内部威胁场景。Ray Arnold 作为一名员工被聘用，并被授权访问 GW 管理控制台设置。我们的组织相信 Ray Arnold 将获得在招聘过程中商定的要求的补偿。然后，管理员在确定应用于 Ray Arnold 的适当权限和角色的范围时，需要承担风险缓解责任。
完成以下操作
- 使用 Ray Arnold 的帐户登录管理控制台
- 选择导航菜单 > 应用 > Google Workspace > Gmail > 路由
- 选择“路由”的配置
- 输入以下信息
- 描述：默认管理员垃圾邮件过滤
- 要影响的电子邮件消息：入站、出站、内部 - 发送、内部 - 接收
- 也传递到：[email protected]
- 要影响的帐户类型：用户
- 信封过滤器：仅影响特定信封收件人（电子邮件地址：[email protected]）
现在我们可以通过从另一个电子邮件（我们使用 Proton 创建了一个随机电子邮件帐户）发送电子邮件给 [email protected] 来测试我们的自定义电子邮件路由，该电子邮件是私密的，并讨论有关新古 DNA 的私密详细信息。发送电子邮件后，您可以查看 Ray Arnold 的 Gmail 并查看此私人电子邮件也被路由到 [email protected]，我们现在可能存在内部威胁，可能会将有关我们的古 DNA 测试的私人信息出售给竞争对手。我们不能允许这种情况发生！
识别自定义 Gmail 路由的潜在检测规则
幸运的是，我们有 Elastic Stack 在我们身边，可以帮助我们通过检测自定义 Gmail 路由创建来阻止这种潜在的内部威胁！在您的 Elastic Stack 中，访问导航菜单 > 分析 > Discover，让我们开始创建我们的 KQL 查询。以下是我们应该查找的查询过滤器和最终查询。
KQL 查询：event.dataset: google_workspace.admin and event.action: "CREATE_GMAIL_SETTING" and not related.user: terrance and google_workspace.admin.setting.name: (MESSAGE_SECURITY_RULE or EMAIL_ROUTE)
让我们进一步分解它来解释我们正在寻找什么
event.dataset: google_workspace.admin - ECS 中的数据源自 GW，特别是管理员报告的文档。由于用户需要是管理员，因此我们应该期望数据源自管理员报告，这也可能表明管理员帐户被泄露或滥用未根据最小权限原则 (PoLP) 设置的管理员。
event.action: "CREATE_GMAIL_SETTING" - Gmail 设置的创建，通常由管理员完成。
not related.user: terrance - 到目前为止，任何由用户名不是“terrance”（预计是唯一接触此类设置的管理员）的管理员创建的 Gmail 设置。
google_workspace.admin.setting.name: (MESSAGE_SECURITY_RULE or EMAIL_ROUTE) - 此设置名称特定于 Gmail 路由规则。
将此查询插入 Discover，我们有匹配的文档，这些文档报告了 GW 中的此活动！
在安全功能中创建自定义规则
让我们通过为此添加我们的自定义检测规则来结束这一切！
要添加您的自定义规则，请完成以下操作
- 在您的 Elastic Stack 中，选择导航菜单 > 安全 > 管理 > 规则
- 选择“创建新规则”
- 输入以下信息
- 定义规则：源、索引模式：logs-google_workspace*
- 自定义查询：我们的自定义查询
我们定义规则元数据
- 名称：创建 Google Workspace 自定义转发电子邮件路由
- 描述：您的选择
- 默认严重性：高
- 标签：Google Workspace
此自定义规则的优点在于，我们可以通过我们选择的平台发送通知，以便在触发此警报时立即收到通知。
然后选择底部的“创建并启用规则”以创建您的自定义规则。如果我们重放上述步骤以创建自定义 Gmail 转发规则，我们现在将看到一个警报并收到有关警报触发器的通知！
此时，我们现在知道 Ray Arnold 已在 GW 中创建了未经授权的自定义 Gmail 路由规则。从 Elastic Stack 中的警报和对 CEO 的通知，我们现在可以采取措施来降低进一步的风险。
要点
如上所示，Elastic 的安全解决方案和 Elastic Stack 允许我们摄取 GW 报告日志并使用预构建的检测规则或自定义规则扫描这些数据。将其与堆栈的其他功能结合使用，例如 企业搜索、可观察性 和非常简单的云堆栈部署流程，我们可以在短时间内开始检测 GW 环境中的威胁。
这是一段漫长的旅程，您已经完成了大量的工作。在本系列的第三部分：检测常见威胁中，我们将模拟威胁参与者的一些常见 Google Workspace 滥用行为，并为这些行为创建更高级的检测逻辑。请做好准备，因为事情将变得更加激烈。
此外，Elastic Stack 中还有很多内容有待探索，正如您可能在本实验中已经发现的那样，因此请随时探索！Elastic 继续采取行动，提高安全透明度，正如 最近 讨论的那样。
希望这能让您更好地了解 Elastic Stack 中强大的功能以及如何使用它来检测 GW 中的潜在威胁。感谢您的阅读/关注，希望我们都能在第三部分中得到检测工程师的帮助。