前言
作为关于 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 Container Project是堆栈的本地 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，其中您的服务帐户将有权从 GW 中提取数据。
配置 OAuth 同意屏幕
接下来，我们需要为我们的服务帐户和应用程序设置OAuth 同意屏幕，以便它们在创建对 GW 的 API 请求时，其中将包含必要的授权令牌。
完成以下步骤
- 选择 Google Cloud 导航菜单 > API 和服务 > 已启用的 API 和服务 > OAuth 同意屏幕
- 用户类型 > 内部 > 创建
- 在后续步骤中填写以下信息
- 应用名称：elastic-agent
- 用户支持电子邮件：[email protected]
- 授权域名：dejesusarcheology.com
- 开发者联系信息：[email protected]
- 保存并继续
- 保存并继续
- 返回仪表板
完成后，我们将拥有一个使用 OAuth 2.0 进行授权的注册应用程序，并且设置了同意屏幕信息。请注意，此应用程序的每日默认令牌请求限制为 10,000 个，但可以增加。我们建议将您的 Elastic Agent 的拉取频率设置为每 10 分钟一次，这样应该不会接近此阈值。设置 Agent 的拉取频率将在稍后的步骤中完成。
创建服务帐户
为了让 Elastic Agent 从 GW 摄取数据，我们需要为 Agent 创建一个服务帐户。此帐户用于非人工应用程序，允许它通过我们之前启用的 Admin SDK API 访问 GW 中的资源。
要创建服务帐户，请执行以下操作
- 在 Google Cloud 中选择导航菜单 > API 和服务 > 凭据 > 创建凭据 > 服务帐户
- 输入以下信息
- 服务帐户名称：elastic-agent
- 服务帐户 ID：elastic-agent
- 将其余部分留空并继续
- 选择您的新服务帐户 > 密钥 > 添加密钥 > 创建新密钥 > JSON
默认情况下，将根据项目继承将 Owner 角色应用于此服务帐户，您可以根据需要更严格地定义权限范围。完成后，您应该拥有一个名为 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 审核报告，这些报告将被转换为 ECS 文档，用于我们的 Elastic Stack。
如果您已经完成到这里，恭喜您，您做得非常出色！您的 GW 和 GCP 环境现在已经设置完成。此时，您几乎已经完成，我们只需要设置 Elastic Stack。
设置您的免费云堆栈
在本实验中，我们将使用免费试用版的云 Elastic，您可以选择使用您的 Google 或 Microsoft 电子邮件帐户。如果您想在现有的云服务提供商 (CSP) 中搭建堆栈，您也可以选择在 Amazon Web Services (AWS)、GCP 或 Microsoft Azure 中创建堆栈。免费试用版会将堆栈部署到 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 集成在 elastic-agent 上，以便访问并将 GW 日志摄取到我们的堆栈中。
创建 Google Workspace 策略
为了让我们的 Elastic Agent 知道它正在使用哪个集成、要收集哪些数据以及将这些数据流式传输到我们堆栈中的哪个位置，我们必须首先设置一个名为 Google Workspace 的自定义 Fleet 策略。
要在您的 Elastic Stack 中设置 Fleet 策略，请在您的 Elastic Stack 中执行以下操作
- 导航菜单 > 管理 > Fleet > Agent 策略 > 创建 Agent 策略
- 输入“Google Workspace”作为名称 > 创建 Agent 策略
在端点上安装 Elastic Agent
如前所述，我们必须在端点上安装至少一个 Agent 才能访问 GW 中的数据，并且将受部署的 GW 策略的约束。我们建议使用一个轻量级的 Linux 主机，无论是本地 VM 还是在 GCP 等 CSP 中，以便将所有内容保持在同一环境中。我将使用我们在处理的同一 GCP 项目中的 Google Compute Engine (GCE) 中的 Ubuntu 20.04 LTS VM 实例。您的端点可以是轻量级的，例如 GCP N1 或 E2 系列，因为它唯一的目的是运行 Elastic Agent。
在设置好您的端点后，请在您的 Elastic Stack 中执行以下操作以部署您的 Agent
- 导航菜单 > 管理 > Fleet > Agent > 添加 Agent
- 确保已选择 GW 策略
- 选择相应的操作系统
- 选择剪贴板图标以复制命令
- 在您的端点上运行命令以安装 Agent
- 完成后，Fleet 应显示一个复选标记，并声明已注册 1 个 Agent 并确认了传入数据
将 Google Workspace 集成分配给 Fleet 策略
我们必须将 GW 集成添加到我们的 GW 策略中，以便它可以从 GW 收集数据并将其流式传输到我们的 Elastic Stack。我们将配置 GW 集成设置，使其具有在设置 GW 环境时创建的信息，以避免在我们的 Ubuntu 主机上出现不安全的凭据。
⚠️ GW 集成的默认间隔为 2 小时，这意味着 Elastic Agent 将每 2 小时检索一次数据，因为可能存在数据保留和延迟时间。这应在集成本身中进行调整，并在您的 Elastic Stack 中的以下步骤中考虑在内
- 导航菜单 > Fleet > Agent 策略 > Google Workspace > 添加集成
- 搜索“Google Workspace” > 选择 Google Workspace
- 选择“添加 Google Workspace”
- 输入此集成的以下信息
- 集成名称：google workspace
- Jwt 文件：复制来自服务帐户创建步骤的 JSON 文件的内容
- 委派帐户：[email protected]（使用您自己的）
- 间隔：10 分钟
- Agent 策略：Google Workspace
- 选择“保存并继续”
- 选择“保存并部署更改”
完成后，您的 GW 集成应分配给您的 GW 策略，并有一个 Agent 分配了此策略。
回顾一下我们到目前为止的 Elastic Stack 设置，我们完成了以下操作
- 部署了 Elastic Stack
- 创建了 Fleet 策略
- 设置了轻量级 Linux 端点
- 将 Elastic Agent 部署到了 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 威胁检测实验室，其中包含 Elastic Security for SIEM！
启用 Google Workspace 检测规则
如前所述，Elastic 不仅针对 Windows、Linux 和 MacOS 端点，而且针对包括 GW 在内的多个集成，拥有 600 多个预构建的检测规则。您可以查看我们当前现有的 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 - 到目前为止，任何管理员创建的 Gmail 设置，其用户名不是“terrance”，而“terrance”是唯一期望接触此类设置的管理员。
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 中的潜在威胁。感谢您的阅读/关注，并祝愿我们所有人都能在第三部分中由检测工程师可靠地掌控。