云主机与对象存储访问痕迹分析

传统主机取证习惯围绕磁盘、进程、网络和日志展开，但一旦事件进入云环境，真正高价值的证据往往藏在 IAM、对象存储、云审计日志和快照导出记录里。很多云上入侵并不会在单台主机上留下特别明显的“木马痕迹”，而是表现为：

某个 Access Key 被异常使用
某个对象存储桶被批量下载
某个快照被导出
某个服务账号突然从异常区域调用大量 API

因此，云取证的重点不是“先上主机抓内存”，而是先弄清楚谁在访问云资源、访问了什么、把什么带出了环境。

0x01 公开案例：GCP 对象存储外传的取证盲区

一个非常值得写进云取证章节的公开案例，是 2023 年 Mitiga 研究经 The Hacker News 报道的 GCP 对象存储外传问题：

攻击者先获得受害组织中的 IAM 身份
然后使用 gsutil 把目标组织的 GCS Bucket 对象复制到攻击者控制的外部 Bucket
问题在于，GCP 当时的某些存储访问日志对“读取对象”“下载对象”“复制对象到外部位置”区分不够清晰

这类案例特别适合蓝队，因为它说明：

云上数据外传不一定表现为一条“主机到公网的大流量”
攻击者完全可能在 CSP 内部用合法 API 完成跨桶转移
如果只盯着主机出口流量，可能根本看不到真正的窃密动作

公开来源：

The Hacker News: Experts Reveal Google Cloud Platform’s Blind Spot for Data Exfiltration Attacks

0x02 云取证要优先回答什么

建议优先回答五个问题：

是哪个身份在调用云资源？ 是用户、角色、服务账号、临时令牌还是实例身份。
访问了哪些对象和实例？ 是对象存储、快照、数据库、Secrets，还是计算实例。
调用是读、列举、复制还是导出？ List、Get、Copy、Export 的风险完全不同。
这些调用是否超出了该身份平时的行为边界？ 包括地区、时间、资源范围和调用频率。
调用后是否发生了更高风险动作？ 例如批量下载、快照导出、访问密钥轮换、日志停用。

0x03 云对象存储事件最常见的攻击链

1. 身份材料泄露

攻击者先拿到：

Access Key
Service Account Token
实例元数据凭据
CI/CD 里的云密钥

2. 资源枚举

常见行为：

列出 Bucket / Container / Blob
查看对象前缀
枚举快照与镜像
拉取 Secret 与配置

3. 批量读取或复制

常见行为：

aws s3 sync
aws s3 cp --recursive
gsutil cp -r
az storage blob download-batch

4. 导出或转储

例如：

导出快照
导出数据库备份
复制对象到外部账户控制的存储桶

0x04 AWS 现场排查命令

1. 查可疑身份最近做了什么

# 查看某个 Access Key 最近使用情况
aws iam get-access-key-last-used --access-key-id AKIAxxxxxxxxxxxx

# 查某个时间窗内与 S3 相关的 CloudTrail 事件
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=GetObject \
  --start-time "2026-06-15T00:00:00Z" \
  --end-time "2026-06-15T23:59:59Z"

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=ListBuckets \
  --start-time "2026-06-15T00:00:00Z" \
  --end-time "2026-06-15T23:59:59Z"

2. 查对象存储是否被批量访问

# 列出 Bucket
aws s3 ls

# 查看某个 Bucket 近期对象
aws s3 ls s3://example-bucket --recursive | tail -n 50

# 查 CloudTrail 中复制/删除/同步相关高风险动作
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=PutObject \
  --start-time "2026-06-15T00:00:00Z" \
  --end-time "2026-06-15T23:59:59Z"

3. 查是否发生快照导出

aws ec2 describe-snapshots --owner-ids self
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateSnapshot \
  --start-time "2026-06-15T00:00:00Z" \
  --end-time "2026-06-15T23:59:59Z"

4. 判断点

如果你看到：

一个平时只跑业务的角色突然执行大量 ListBucket/GetObject
同时该身份来自异常 IP 或异常地域
随后又出现快照、镜像或对象复制

那就非常接近云上数据外传事件。

0x05 GCP 现场排查命令

1. 查对象存储访问

# 列 Bucket
gsutil ls

# 列某个 Bucket 对象
gsutil ls -r gs://example-bucket/**

# 查看审计日志中与 GCS 相关事件
gcloud logging read \
  'resource.type="gcs_bucket" AND timestamp>="2026-06-15T00:00:00Z"' \
  --limit 100 --format=json

2. 查是否存在批量复制或下载

# 查服务账号近期活动
gcloud logging read \
  'protoPayload.authenticationInfo.principalEmail:"service-account" AND timestamp>="2026-06-15T00:00:00Z"' \
  --limit 200 --format=json

# 查与对象读取相关的日志
gcloud logging read \
  'resource.type="gcs_bucket" AND protoPayload.methodName:"storage.objects.get" AND timestamp>="2026-06-15T00:00:00Z"' \
  --limit 200 --format=json

3. 排查思路

对照前面的 GCP 公开案例，重点看：

某个 IAM 身份是否在短时间内访问大量对象
访问对象的前缀是否明显高价值
调用来源是否异常
是否存在 gsutil cp -r 一类批量复制痕迹

0x06 Azure 现场排查命令

1. 查活动日志与存储访问

# 查询活动日志
az monitor activity-log list \
  --start-time 2026-06-15T00:00:00Z \
  --end-time 2026-06-15T23:59:59Z

# 列出存储账号
az storage account list -o table

# 列出容器
az storage container list --account-name mystorageacct --auth-mode login -o table

# 批量列出 Blob
az storage blob list --account-name mystorageacct --container-name data --auth-mode login -o table

2. 查是否有批量下载或导出行为

# 下载命令示例本身就是高风险动作，应重点在 Shell 历史和活动日志中搜索
grep -RInE 'az storage blob download|az storage blob download-batch|azcopy copy' ~/.bash_history ~/.zsh_history 2>/dev/null

0x07 云主机侧的补充取证

不要忘了，很多云事件虽然发生在 API 层，但主机上仍然有旁证：

1. Linux 云主机

# 查实例元数据调用痕迹
grep -RInE '169\.254\.169\.254|metadata.google.internal|AzureInstanceMetadata' /root/.bash_history /home/*/.bash_history 2>/dev/null

# 查 AWS/GCP/Azure CLI 使用历史
grep -RInE 'aws s3 |aws ec2 |gcloud |gsutil |az storage |azcopy ' /root/.bash_history /home/*/.bash_history 2>/dev/null

# 查云密钥文件
find /root /home -type f \( -name "credentials" -o -name "config" -o -name "application_default_credentials.json" \) 2>/dev/null

2. Windows 云主机

Get-ChildItem "$env:USERPROFILE\.aws","$env:USERPROFILE\.azure","$env:APPDATA\gcloud" -Recurse -Force -ErrorAction SilentlyContinue |
  Select-Object FullName, LastWriteTime

$start=(Get-Date).AddDays(-3)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=$start} |
  Where-Object {$_.Message -match 'aws\.exe|gcloud\.exe|gsutil|az\.exe|azcopy'} |
  Select-Object TimeCreated, Message

0x08 一条可直接执行的云取证流程

如果你怀疑某个云账号或云主机被用于访问对象存储，建议直接按下面顺序执行：

先锁定异常身份：用户、角色、服务账号、实例身份
再按时间窗导出审计日志：CloudTrail、GCP Audit Logs、Azure Activity Logs
再聚焦高风险动作：List/Get/Copy/Export/Snapshot
再回到主机侧查 CLI、历史命令、密钥文件和元数据访问
最后确认是否已经发生对象批量读取、跨桶复制或快照导出

0x09 三个常见误区

1. 只盯主机出口流量

云上的数据复制很多时候发生在 CSP 内部 API 之间，未必表现为传统主机到公网的大流量。

2. 只看登录，不看资源调用

真正决定风险大小的不是“谁登录了云控制台”，而是“登录之后调用了哪些资源 API”。

3. 只看对象存储，不看快照与镜像

很多组织把数据库和磁盘快照视作“基础设施资源”，但攻击者眼里它们本质上就是另一种高价值数据包。

0x0A 建议的交付结构

云对象存储事件适合整理为如下表格：

时间	证据源	事件	关联身份/资源	结论
01:02:14	CloudTrail / Audit Log	列举 Bucket	`svc-app`	开始资源枚举
01:04:31	Audit Log	批量读取对象	`example-bucket`	高价值对象被访问
01:06:12	CLI / 主机历史	`gsutil cp -r` / `aws s3 sync`	云主机	存在批量复制行为
01:09:55	审计日志	快照导出 / 跨桶复制	`snapshot-xxx`	数据外传链成立
01:12:40	处置建议	失效密钥 / 禁止角色 / 保全日志	IAM / Bucket	需立即阻断

0x0B 总结

云取证的核心，不再是“这台机器上有没有恶意文件”，而是：

哪个身份拿到了云资源访问能力
访问了哪些 Bucket、快照、对象和密钥
是否发生了批量读取、复制、导出和外传
这些动作是否还能继续发生

当你把身份、审计日志、对象访问、快照导出和主机 CLI 痕迹串成同一条时间线时，云上事件才真正从“账号异常”升级为“可落地、可定界、可处置”的取证分析结果。