2026-06-18 05:52:07 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文剖析攻击者滥用AWSCloudTrail和GoogleCloudLogging等云日志服务的两大技术路径：防御规避（通过停止日志记录、删除存储目标/路由器、加密密钥操控、日志投毒等手段制造盲点）和持续可见性（通过配置新日志路由或重定向日志到攻击者环境实现被动监控）。文档详细演示各技术操作流程，并强调此类攻击对安全监控的破坏性，建议组织加强日志配置保护与异常检测机制。 综合评分： 85 文章分类： 云安全,威胁情报,安全运营,漏洞分析,解决方案

cover_image

致盲哨兵：云日志服务滥用技术剖析

Dubito Dubito

云原生安全指北

2026年6月11日 08:35 江苏

在小说阅读器读本章

去阅读

注：本文翻译自 Unit 42 的文章《Blinding the Watchmen: Abusing Cloud Logging Services for Defense Evasion and Visibility》[1]，可点击文末“阅读原文”按钮查看英文原文。

执行摘要

云日志服务提供了对云资源内操作的全面可见性。因此，它们对安全监控至关重要。然而，这种依赖也使得日志服务成为攻击者的高价值目标。成功利用这些服务的攻击者可以制造盲点、躲避检测，并在某些情况下，在目标环境中建立持续可见性。

像 Amazon Web Services (AWS) CloudTrail 和 Google Cloud 这样的服务，对防御者来说功能强大，而对于试图通过破坏日志流来保持不被发现的攻击者而言，则是首要目标。针对云日志服务的攻击技术主要分为两类：

• 防御规避： 攻击者旨在绕过检测系统，以在无人察觉的情况下执行攻击。这可能涉及修改云日志服务内的资源。
• 持续可见性： 攻击者试图将日志传输到自己的账户，从而对受害者的环境建立持续可见性。

理解这些攻击场景，可以帮助组织实施适当的配置并检测服务滥用。

一、云日志服务

作为每个事件的权威记录系统，云日志服务提供了对云环境内所有操作的完全可见性。这些全面的数据支持对过往行为进行分析，既可用于操作调试，也可用于安全调查。

每个云提供商实现日志服务的方式都独一无二。我们最近的文章《用于安全的云日志记录（Cloud Logging for Security）[2]》概述了不同云提供商的多种日志服务。在本文中，我们分析并演示了针对每个主要云提供商的核心日志服务的攻击技术。

在探讨主要云提供商提供的日志记录能力之前，我们首先概述日志交付的基本组成部分和机制。我们的分析聚焦于 AWS CloudTrail 和 Google Cloud Logging。这两个广泛使用的服务都旨在提供全面的审计追踪和操作洞察。虽然本文聚焦于特定服务，但所展示的攻击技术也可能适用于其他云日志服务。

二、背景：云服务提供商如何处理日志

2.1 AWS CloudTrail

AWS CloudTrail 用于可配置日志收集和投递的主要资源称为 trail。trail[3] 是一种配置，它指定 CloudTrail 如何记录 AWS 应用程序编程接口（API）调用以及 AWS 账户中的相关事件。这些事件包括用户、角色或 AWS 服务所执行的操作。

trail 的主要功能是将这些捕获到的日志投递到一个 Amazon S3 存储桶[4]。S3 是一个高可扩展、高持久、安全的对象存储服务。配置 trail 后，它会持续将包含事件记录的日志文件写入指定的 S3 存储桶。

S3 存储桶充当 CloudTrail 日志的集中式长期存储库。这有助于审计、安全分析和合规工作。CloudTrail 支持将原生事件 trail 发送到 CloudTrail Lake 、EventBridge 或 CloudWatch Logs。但是，对于需要集成第三方产品的企业来说，这些功能可能不相关或无法使用。

2.2 Google Cloud Logging

Cloud Logging 是一项全托管服务，用于收集组织中所有 Google Cloud 资源的日志。Cloud Logging 利用称为 sink 的资源作为日志投递的主要机制。sink[5] 的功能类似于路由器，将日志条目发送到特定目标。虽然 sink 主要将日志路由并存储到集中式 log bucket[6] 中用于分析和留存，但它也提供了将日志导出到其他强大的 Google Cloud 服务的灵活性。例如，日志可以被发送到云存储桶，以实现经济高效的长期归档。配置 sink 后，它会将与过滤器定义的特定条件相匹配的日志条目导出到指定的 log bucket。

三、防御规避

复杂技术使攻击者能够在受感染的云环境中保持不被发现。这些方法可能涉及操纵或规避（对安全监控和事件响应至关重要的）日志记录机制。被掩盖的活动可以延长攻击者的存在时间，便于数据外泄，或在被发现之前造成更大的损害。

包括以下在内的大量安全产品，其运行从根本上依赖这些日志数据：

• 安全信息和事件管理（SIEM）
• 安全编排、自动化与响应（SOAR）平台
• 专业的云安全态势管理（CSPM）工具

通过禁用、修改或删除这些日志，攻击者可以有效地将这些防御系统蒙在鼓里，从而损害整个云环境的安全完整性。攻击者经常使用以下五种技术来实现此目的：

1. 停止日志记录
2. 删除日志存储目标
3. 删除日志路由器
4. 通过攻击者控制的加密密钥削弱日志记录
5. 日志投毒

3.1 技术 1：停止日志记录

暂停日志流最直接的方法是禁用日志记录机制本身。大量安全产品的运行从根本上依赖这些日志数据。通过禁用这些日志，攻击者可以有效地让防御系统失明，破坏整个云环境的安全完整性。

• 在 AWS 中，拥有 cloudtrail:StopLogging 权限的攻击者可以对特定 trail 调用 stop-logging API。一旦执行此 API，该 trail 的后续日志将不再写入 S3 存储桶，对于自行创建 trail 的组织来说，会立即产生可见性缺口。
• 在 Google Cloud 中，等效操作是禁用 sink。拥有 logging.sinks.update 权限的攻击者可以将 sink 的 disabled 字段设为 true，以停止日志写入。图 1 所示的 Google Cloud 控制台消息反映了这一变化。

图 1. 确认日志暂停的消息。

3.2 技术 2：删除日志存储目标

通常，日志存储在云存储资源中。获得此资源权限的攻击者可以删除云存储，从而阻止日志写入。以下场景演示了这种能力。

• 在 AWS 中，拥有 s3:DeleteBucket 权限的攻击者可以使用 delete-bucket API 删除 S3 存储桶；此操作还需要 s3:DeleteObject 权限来清空存储桶。操作后几分钟，关联的 CloudTrail trail 配置将指示此删除，如图 2 中的通知所示。

图 2. AWS CloudTrail 中存储桶删除的指示。

• 在 Google Cloud 中，拥有 logging.buckets.delete 权限的攻击者可以删除 log bucket。对于 log bucket，删除并非立即执行。发出删除命令后，log bucket 会进入 DELETE_REQUESTED 状态，并保持该状态七天。在此之后，存储桶才会被删除。 Google Cloud 提供了一种机制[7]来防止此类删除，即提供锁定 log bucket 的能力。一旦存储桶被锁定，其保留策略将变为永久且不可逆，这意味着在任何用户完成指定保留期限内的所有日志条目之前，都无法删除该存储桶。

3.3 技术 3：删除日志路由器

另一种防御规避策略是删除日志路由资源——例如，AWS trail 或 Google Cloud sink。一旦删除，新的日志将停止写入指定的目标。攻击者可以使用 AWS 的 delete-trail API 或 Google Cloud 的 google.logging.v2.ConfigServiceV2.DeleteSink 方法来删除日志路由器。

3.4 技术 4：通过攻击者控制的加密密钥削弱日志记录

攻击者可能通过修改加密密钥使云日志不可读。在 AWS 中的攻击流程如下：

• 在 AWS 中创建 trail 时，配置参数之一是密钥管理服务（KMS）密钥，用于加密 CloudTrail 投递的日志。
• 攻击者可以通过更新 trail 以使用攻击者控制的 KMS 密钥，然后移除对该密钥的访问权限，从而阻止对原始密钥的合法访问。
• 因此，由于无法使用无效的密钥加密日志，日志将不会被写入存储桶。
• 要执行此攻击，攻击者首先使用图 3 所示的策略创建一个外部 KMS 密钥，以确保 CloudTrail 可以访问该密钥。

图 3. 创建具有外部访问权限的 KMS 密钥的策略。

• 攻击者使用 update-trail API 修改用于加密 S3 存储桶中日志的 KMS 密钥。
• 接下来，攻击者通过删除密钥或从策略中移除 Allow CloudTrail to access the key 语句，来撤销 CloudTrail 对该密钥的访问权限。随后，即使存储桶配置正确，CloudTrail 也会指示存在配置问题，因为存储桶访问被拒绝。
• 从此时起，由于 KMS 密钥无法访问，日志将不会写入存储桶。图 4 显示了禁用访问后显示的消息。

图 4. 禁用对 KMS 密钥的访问会导致“存储桶访问被拒绝”错误。

图 5 展示了在 AWS 中的攻击流程。

图 5. 在 AWS 中通过攻击者控制的加密密钥削弱日志记录的攻击流程。

在 Google Cloud 中使用此技术的攻击流程如下：

• 在 Google Cloud 中，可以模拟类似的攻击场景：假设一个 log bucket 已预先配置了客户管理的加密密钥（CMEK）。然后，攻击者可以利用此现有配置，使用以下命令修改 CMEK 使其引用一个外部密钥（外部 CMEK 必须被授予 KMS 服务账户加密/解密访问权限[8]）：gcloud logging buckets update BUCKET_NAME --location=LOCATION --cmek-kms-key-name FULL_KMS_KEY_NAME

随后，攻击者可以移除授予外部密钥的权限。此时，受害者将无法读取日志，如图 6 中的 Google Cloud 面板所示。

图 6. 无法访问加密密钥的结果。

任何尝试恢复密钥的操作都会导致错误消息“rekeying requires that the CMEK service account has decrypt access to the current CMEK key”，如图 7 所示。

图 7. 尝试恢复密钥的结果。

3.5 技术 5：日志投毒

另一种防御规避技术是直接修改日志——即所谓的日志投毒。当日志预先配置为写入云存储资源时，这是一种有效的技术。在这种情况下，日志以 JSON 格式存储，并且可以被攻击者修改。如果存储的日志被删除、添加或修改，安全运营中心（SOC）人员或分析员极有可能在不知不觉中使用这些被投毒的日志进行日志分析。

• 在 AWS 中，CloudTrail 日志作为对象投递到 S3 存储桶。对该存储桶拥有 s3:GetObject 和 s3:PutObject 权限的攻击者可以下载日志文件，删除或更改特定事件，然后重新上传，覆盖原始文件。这会破坏证据链并使审计追踪失效。
• 图 8 显示了一个场景中的查询响应：攻击者修改日志以避免检测，然后受害者使用 Amazon Athena[9] 检查该日志。

图 8. Athena 查询分析显示被修改的日志。

• 在 Google Cloud 中，sink 将日志路由到云存储。拥有 storage.objects.get 和 storage.objects.create 权限的攻击者可以执行相同的下载和覆盖技术。

为了降低日志投毒的风险，AWS 提供了 CloudTrail 日志文件完整性验证[10]功能。该功能能够以密码学方式验证日志文件在由 CloudTrail 投递后是否被修改。使用 AWS 控制台创建 trail 时，此功能默认启用，但使用 API 或命令行界面（CLI）时则不会。

四、持续可见性

在受害者环境中获得初步立足点后，拥有进阶能力的攻击者会试图建立对受害者云基础设施的长期、被动的可见性。攻击者不会运行可能触发警报的、嘈杂的发现命令——或者在他们缺乏适当权限的情况下——而是瞄准日志传输机制，将日志路由到自己的环境，从而实现实时可见性。这使得攻击者能够执行持续发现，并被动监控所有活动（从新的虚拟机部署、 IAM 策略变更，到敏感数据访问）。通过这种方式，攻击者可以绘制环境地图，识别高价值目标，并提升权限，同时几乎不会被受害者的安全监控系统发现。以下技术可实现持续可见性：

1. 配置新的日志路由资源
2. 日志重定向

4.1 技术 1：配置新的日志路由资源

实现持续可见性的一种直接方法是创建新的日志路由资源——例如，AWS trail 或 Google Cloud sink。攻击者配置新创建的资源，将日志定向到外部的、攻击者控制的目标。

• 在 AWS 中，攻击者使用 create-trail API 并将自己的存储桶指定在 --s3-bucket-name 参数中，从而将 CloudTrail 日志配置到他们自己的 S3 存储桶。
• 在 Google Cloud 中，攻击者利用 logging.sinks.create API 将 DESTINATION 参数设置为攻击者预期的资源。

上述两个步骤都会导致所有日志被定向到攻击者选择的目标。

对于某些 AWS 账户，CreateTrail 操作会显示在 CloudTrail 中。如果在设置 AWS 账户时配置了 EventBridge，防御方可以使用 EventBridge 对创建事件发出警报。在这种设置下，后续对 CloudTrail 配置的 describe 调用将显示攻击者的目标存储桶。但是，对于使用第三方服务或未应用这些配置的组织，攻击者可以在不被检测到的情况下进行恶意活动。

4.2 技术 2：日志重定向

使用此技术时，攻击者会将日志路由目标更改到他们自己环境中的某个目标。这会将日志重定向到攻击者控制的资源，使攻击者能够获得持续发现能力。

• 在 AWS 中，攻击者在调用 update-trail API 时更新 --s3-bucket-name 参数。修改目标存储桶后，所有日志都会被定向到攻击者的存储桶，从而为攻击者提供对受害者账户的持续发现能力。
• 在 Google Cloud 中，攻击者使用 logging.sinks.update 权限来更新 destination 参数，达到同样的日志重定向能力。

那些自行处理警报和遥测数据的小型企业可能会注意到在这种情况下 trail 已停止工作，但大型组织可能没有使用 AWS 原生服务，而这些服务本可以帮助他们检测到这种异常行为。

五、风险与影响评估

表 1 总结了各种规避与可见性的技术、活动为恶意的可能性以及对日志服务的主要影响。

表 1. 规避与可见性技术的风险与影响评估

六、预防与意识

所讨论的攻击场景都源于对日志服务资源的修改。鉴于云日志服务资源的高价值，应仅限高权限用户访问，以帮助预防这些场景。此措施可降低攻击者更改此类资源配置的可能性。

6.1 AWS

每个 AWS 账户都有一个不可变的 90 天 CloudTrail 事件历史[11]，包含所有管理事件。这个回退机制确保这些记录无法被删除或绕过。但是，数据事件和网络事件不会出现在此历史记录中。

在 AWS 中，将 update-trail API 的调用权限限制为仅限高权限用户。配置关联 S3 存储桶的存储桶策略，防止非管理员用户进行配置修改。同样至关重要的是，确保只有 CloudTrail 服务才能将对象写入这些存储桶。

6.2 Google Cloud

Google Cloud 通过其内置 log bucket[12] 提供了与 AWS 类似的安全机制。_Required log bucket 作为一个不可变的存储库，用于存放基本日志（例如管理员活动和系统事件审计日志），这些日志无法被禁用、修改或删除。与此并列的是，_Default log bucket 会在较短时间内自动捕获更广泛的日志条目。当为外部集成目的创建日志存储时，这些内置存储桶将不相关。因此，那些手动配置的存储桶可能仍然暴露于本文所述的特定攻击技术之下。

在 Google Cloud 中，应限制 logging.sinks.update 的权限，并保护目标资源。

七、结论

云日志服务对于维护安全态势和运营感知至关重要，它提供了云环境中所有活动的权威记录。日志基础设施本身的完整性是一个关键的控制点，正因如此，它已成为那些企图不被发现而进行恶意活动的攻击者的主要攻击目标。

滥用云日志服务可能会带来严重的负面后果，使攻击者能给安全团队造成盲点，实时窃取敏感数据，或有条不紊地掩盖其踪迹以逃避取证。通过理解威胁行为者针对这些服务使用的具体 TTP（战术、技术与程序），防御方可以建立更具弹性的检测和预防策略。

补充资源

• CloudTrail 概念[3] – AWS
• CloudTrail 事件历史[11] – AWS
• 通用存储桶概述[4] – AWS
• 什么是 Amazon Athena？[9] – AWS
• 验证 CloudTrail 日志文件完整性[10] – AWS
• 聚合 sink 概述[13] – Google Cloud
• 为 Cloud Logging 配置 CMEK[8] – Google Cloud
• Log bucket[6] – Google Cloud
• Logging Bucket 锁定[7] – Google Cloud
• 系统创建的 Log Bucket[12] – Google Cloud
• 什么是 Pub/Sub？[14] – Google Cloud
• 云日志安全及其他[2] – Unit 42

Cortex XDR 对云日志服务滥用的告警

表 2 显示了针对云日志服务中的此类活动所触发的 Cortex 告警。

表 2. 指示云日志服务中恶意活动的 Cortex 告警

引用链接

[1] 《Blinding the Watchmen: Abusing Cloud Logging Services for Defense Evasion and Visibility》: https://unit42.paloaltonetworks.com/cloud-logging-defense-evasion/ [2] 用于安全的云日志记录（Cloud Logging for Security）: https://unit42.paloaltonetworks.com/cloud-logging-for-security/ [3] trail: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-concepts.html#cloudtrail-concepts-trails [4] S3 存储桶: https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html [5] sink: https://docs.cloud.google.com/logging/docs/export/configure_export_v2 [6] log bucket: https://docs.cloud.google.com/logging/docs/buckets [7] 机制: https://docs.cloud.google.com/logging/docs/buckets#locking-logs-buckets [8] CMEK 必须被授予 KMS 服务账户加密/解密访问权限: https://docs.cloud.google.com/logging/docs/routing/managed-encryption#assign-role [9] Amazon Athena: https://docs.aws.amazon.com/athena/latest/ug/what-is.html [10] CloudTrail 日志文件完整性验证: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-validation-intro.html [11] 事件历史: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html [12] 内置 log bucket: https://docs.cloud.google.com/logging/docs/store-log-entries#system-created [13] 聚合 sink 概述: https://cloud.google.com/logging/docs/export/aggregated_sinks_overview [14] 什么是 Pub/Sub？: https://docs.cloud.google.com/pubsub/docs/overview [15] AWS CloudTrail 已停止: https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDR-Analytics-Alert-Reference-by-Alert-name/AWS-CloudTrail-has-been-stopped [16] AWS CloudTrail 修改: https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDR-Analytics-Alert-Reference-by-Alert-name/AWS-CloudTrail-modification [17] Google Cloud logging sink 修改: https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDR-Analytics-Alert-Reference-by-Alert-name/GCP-logging-sink-modification [18] Google Cloud Logging Bucket 删除: https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDR-Analytics-Alert-Reference-by-Alert-name/GCP-Logging-Bucket-Deletion [19] CloudTrail 日志删除: https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDR-Analytics-Alert-Reference-by-Alert-name/CloudTrail-logging-deletion [20] Google Cloud logging sink 删除: https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDR-Analytics-Alert-Reference-by-Alert-name/GCP-logging-sink-deletion [21] 通过外部加密密钥削弱日志记录: https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDR-Analytics-Alert-Reference-by-Alert-name/Logging-was-impaired-via-external-encryption-key [22] logging bucket 上的可疑活动: https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDR-Analytics-Alert-Reference-by-Alert-name/Suspicious-activity-on-logging-bucket

交流群

知识库

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：云原生安全指北 Dubito Dubito《致盲哨兵：云日志服务滥用技术剖析》